INFORMATICA Q SL

INFORMATICA Q SL era una societat mercantil espanyola amb domicili a Madrid, classificada dins del sector del software i SaaS. La seva raó social consta com a INFORMATICA Q SL.

Segons la fitxa registral publicada a OpenMercantil a partir del BORME, la societat es va constituir l'any 2026 i el mateix any va quedar inscrita en situació concursal. Es tracta, per tant, d'una companyia de vida registral molt curta: no consta que arribés a operar de manera sostinguda abans de l'obertura del concurs.

D'acord amb el registre, la constitució de la societat es va produir l'any 2026. Les dades disponibles no inclouen la data exacta de l'escriptura de constitució, l'import del capital social, la forma de constitució (simultània o successiva) ni la identitat dels socis fundadors.

Tampoc no consta a la documentació consultada quina era l'estructura accionarial inicial ni si hi va haver ampliacions de capital o entrades d'inversors abans de la declaració de concurs.

La classificació sectorial disponible situa l'empresa en l'àmbit del software i SaaS. Més enllà d'aquesta adscripció genèrica, no consta quin producte o servei concret oferia, quin model de negoci tenia (subscripció, llicència, serveis professionals), a quin segment de clients s'adreçava ni quina dimensió de facturació o plantilla va assolir.

Atesa la cronologia registral —constitució i concurs dins del mateix any 2026—, no hi ha constància que l'empresa hagués consolidat una cartera de clients o una activitat comercial estable abans de la insolvència.

No consta cap període d'activitat pròspera. La seqüència registral disponible mostra una constitució el 2026 i una inscripció de situació concursal el 21 d'agost de 2026, sense que les dades permetin identificar exercicis amb resultats positius, creixement de clients o fites comercials.

L'única informació verificada és que, segons el BORME (fitxa a OpenMercantil, 21 d'agost de 2026), la societat va quedar inscrita en situació concursal. El registre no detalla en la informació disponible la causa de la insolvència, l'import del passiu, la identitat dels creditors ni si el concurs va derivar en liquidació.

No consta, per tant, si el concurs va ser conseqüència d'una manca de finançament, d'un producte que no va trobar mercat, de costos superiors als ingressos o d'altres factors. Qualsevol afirmació en aquest sentit seria una suposició no recolzada per les fonts.

No consta que la societat deixés cap actiu rellevant, producte en funcionament, cartera de clients o propietat intel·lectual transferida a tercers. La informació registral disponible no inclou el resultat del procediment concursal ni eventuals operacions de venda d'actius.

Les dades disponibles no identifiquen els fundadors ni els administradors de la societat, de manera que no consta quina és la seva situació actual ni si han impulsat altres projectes.

Per completar aquesta informació es podria consultar la fitxa completa de la societat al Registre Mercantil de Madrid, la certificació d'actes registrals (nomenaments i cessaments d'administradors) i el Registre Públic Concursal, que recull l'identitat de l'administrador concursal i l'estat del procediment.

• En el sector del software i SaaS, el cicle entre constitució i primera facturació recurrent pot ser llarg; una societat que neix i concursa dins del mateix any suggereix que caldria verificar, en casos similars, si el pla de finançament cobria el període previ a l'arribada d'ingressos recurrents.
• La inscripció concursal al BORME és la primera dada pública fiable sobre la salut d'una societat de nova creació; per a un analista, la data de constitució i la data de concurs són dos indicadors objectius que permeten mesurar la durada real del projecte sense dependre de la narrativa de l'empresa.
• Quan una companyia tecnològica concursa molt aviat, la informació rellevant per entendre què va fallar (capital inicial, socis, creditors) es troba al Registre Mercantil i al Registre Públic Concursal, no a la nota de premsa; convé consultar-los abans de treure conclusions sobre les causes.

No hi ha res verificat sobre què feia INFORMATICA Q SL més enllà del seu sector declarat (software i SaaS) i la seva seu a Madrid. No consta producte, ni cartera de clients, ni equip, ni finançament. L'únic fet és que va entrar en situació concursal el 2026, el mateix any de la seva constitució [BORME / BOE via OpenMercantil, 2026-08-21].

Això limita molt el que es pot "reconstruir". El que sí que es pot fer avui és muntar una empresa de software amb la mateixa essència formal —SL madrilenya, sector SaaS— però amb una diferència de disseny: començar pel contracte i no pel codi.

Proposta (no verificada): un micro-SaaS vertical de servei, és a dir, una eina petita per a un nínxol concret, venuda amb implantació i suport inclosos, en lloc d'un producte autoservei. El nínxol concret és una decisió oberta; el que importa és el patró: nínxol estret, preu alt per client, pocs clients per cobrir costos.

No hi ha dades verificades del mercat que atenia INFORMATICA Q SL. El que es pot afirmar amb seguretat és que Madrid és un mercat dens en software B2B i que el 2026 el cost d'aixecar un SaaS és baix (infraestructura al núvol per consum, eines de desenvolupament madures).

Estimació (a validar): un micro-SaaS vertical a Espanya pot aspirar a un mercat adreçable de centenars a pocs milers d'empreses per nínxol, amb disposició a pagar de l'ordre de 100–500 €/mes per una eina que estalviï hores de feina. Són xifres de treball, no dades de mercat contrastades; caldria validar-les amb 15–20 entrevistes a compradors reals abans de comprometre-hi res.

Proposta: subscripció mensual amb implantació inicial de pagament.

• Ingressos recurrents: quota mensual per empresa usuària.
• Ingressos d'entrada: una quota única d'implantació i configuració, que finança el cost d'adquisició del client des del primer dia.
• Retenció: el suport inclòs és el que justifica el preu alt; sense suport, el client compara amb eines gratuïtes.

Estimació (a validar): amb un preu mitjà de 200 €/mes i un cost de servei de 40 €/mes per client, caldrien de l'ordre de 25–40 clients actius per cobrir un cost fix mínim d'un fundador i infraestructura. Són números de planificació, no projeccions validades.

1. Mesos 0–1 — Validació comercial abans de codi. Triar un nínxol, fer 15–20 entrevistes, aconseguir 3 cartes d'intenció o prepagaments. Si no n'hi ha, canviar de nínxol.
2. Mesos 1–3 — Producte mínim. Construir només el flux que el client pagaria per resoldre. Un sol cas d'ús, no una plataforma.
3. Mesos 3–6 — Primers clients de pagament. Objectiu: 3–5 clients amb implantació cobrada. Aquí es mesura si el model funciona.
4. Mesos 6–12 — Repetició. Documentar la implantació perquè no depengui del fundador, i decidir si cal soci tècnic o comercial.

El criteri d'aturada hauria de ser explícit des del principi: si al mes 6 no hi ha clients de pagament, es tanca o es pivota, no s'amplia la despesa.

Estimació (rang de, a validar):

• Constitució de SL i gestoria inicial: 500–1.500 €.
• Infraestructura i eines de desenvolupament, primers 12 mesos: 1.500–4.000 € (depèn del consum).
• Màrqueting i vendes inicials (web, materials, prospecció): 2.000–6.000 €.
• Cost d'oportunitat del fundador: el cost real més gran; si no es cobra sou els primers mesos, cal comptar-lo com a inversió.

Total d'inversió directa estimada: 4.000–12.000 € per als primers 12 mesos, sense comptar sous. És una forquilla àmplia perquè depèn de si el desenvolupament el fa el fundador o es subcontracta.

• Risc de repetir el patró. Una SL constituïda i concursada el mateix any suggereix que el problema no era el mercat sinó la caixa o la validació. El pla ha de tenir un criteri d'aturada i un coixí de tres mesos de despesa.
• Risc de producte sense client. Construir abans de vendre és la manera més habitual de cremar els 4.000–12.000 € sense aprendre res.
• Risc de nínxol massa estret o massa ampli. Massa estret: no hi ha prou clients per cobrir costos. Massa ampli: competència directa amb eines gratuïtes.
• Risc de dependència del fundador. Si la implantació no es pot delegar, el negoci no escala i el fundador es converteix en coll d'ampolla.
• Risc d'informació. No hi ha dades verificades de l'empresa original; qualsevol afirmació sobre "el que feia" seria inventada i no s'ha de fer servir per justificar el pla.

Les lliçons de l'expedient original són poques però clares, i totes són de procés, no de persona:

1. Constituir i concursar el mateix any indica que la constitució es va fer abans de tenir un client, no després. El pla invers és més barat.
2. El registre només diu "situació concursal": no hi ha rastre de producte ni de clients. Això recorda que una SL no és un negoci; és un embolcall. El negoci és el contracte.
3. La seu a Madrid i el sector SaaS no són un pla. Són una categoria. El pla és un nínxol, un preu i un comprador concret.

Per tant, qui ho hauria de fer és algú que accepti començar per la venda i no pel codi, que fixi un criteri d'aturada per escrit i que no gasti més del que pot perdre en 12 mesos. El perfil concret —fundador sol, parella tècnica-comercial, o equip de dos— és una decisió oberta; el que no és opcional és l'ordre: validar, cobrar, després construir.

Les micropimes espanyoles (1-10 treballadors) facturen amb eines com Holded, Factusol o fulls de càlcul, i reben extractes bancaris en CSV o PDF de CaixaBank, BBVA, Santander i Sabadell. Conciliar factura contra moviment és manual: el gestor o el propi autònom obre l'extracte, busca l'import, comprova el número de factura al concepte i marca. Amb 80-200 moviments mensuals, això són 2-4 hores al mes que ningú factura.

El producte que proposo és un servei web que rep factures (CSV/PDF) i extractes (CSV/OFX), proposa emparellaments amb una puntuació de confiança, i permet confirmar o rebutjar en bloc. L'asiento conciliat s'exporta al format del programa comptable del client.

Motiu de la tria: és un problema de dades estructurades amb regles clares, no requereix integracions bancàries PSD2 (que encarien el producte), i el mercat objectiu paga per estalvi de temps mesurable.

Monòlit modular desplegat en un sol contenidor més un worker. Motiu: amb un equip d'1-3 persones i un ARPU de 20 €/mes, microserveis multipliquen el cost operatiu sense benefici. Els mòduls es comuniquen per interfície interna en Python, no per xarxa.

``` [Client web (React SPA)] | v [API FastAPI] ---> [Postgres 16] | ^ | | +--> [Redis] --> [Worker de matching (Python)] | +--> [Almacenamiento S3-compatible per a PDFs originals] ```

• API FastAPI: autenticació per JWT, endpoints REST, validació amb Pydantic.
• Postgres: dades transaccionals i resultats de matching. Taules amb `tenant_id` i Row-Level Security per aïllament multi-tenant.
• Redis + worker: la ingesta de PDF i el matching són tasques llargues (5-30 s); es desacoblen de la petició HTTP per evitar timeouts.
• S3-compatible (MinIO en dev, Backblaze B2 en prod): es guarden els PDFs originals per auditoria i reprocessament. Motiu: si el parser falla, es pot reintentar sense demanar al client que torni a pujar el fitxer.
• Parser de PDF: `pdfplumber` amb plantilles per banc (regex sobre capçaleres conegudes). Motiu: els extractes PDF no tenen format estàndard i una plantilla per banc és més fiable que un model genèric per a un catàleg de 4-6 bancs.

Esquema relacional a Postgres. Totes les taules de negoci porten `tenant_id UUID NOT NULL` i política RLS.

```sql -- Tenant i usuaris CREATE TABLE tenant ( id UUID PRIMARY KEY, nom TEXT NOT NULL, programa_comptable TEXT CHECK (programa_comptable IN ('contaplus','a3','csv')), creat_el TIMESTAMPTZ DEFAULT now() );

CREATE TABLE usuari ( id UUID PRIMARY KEY, tenant_id UUID NOT NULL REFERENCES tenant(id), email CITEXT UNIQUE NOT NULL, hash_contrasenya TEXT NOT NULL );

-- Ingesta CREATE TABLE document_pujat ( id UUID PRIMARY KEY, tenant_id UUID NOT NULL, tipus TEXT CHECK (tipus IN ('factura','extracte')), nom_fitxer TEXT, clau_s3 TEXT NOT NULL, estat TEXT CHECK (estat IN ('pendent','processat','error')), error TEXT, creat_el TIMESTAMPTZ DEFAULT now() );

-- Moviments d'extracte CREATE TABLE moviment ( id UUID PRIMARY KEY, tenant_id UUID NOT NULL, document_id UUID REFERENCES document_pujat(id), data DATE NOT NULL, import NUMERIC(12,2) NOT NULL, -- signe: negatiu = càrrec concepte TEXT, referencia TEXT, -- número de factura si apareix al concepte hash_unic TEXT NOT NULL, -- sha256(data|import|concepte) per idempotència UNIQUE (tenant_id, hash_unic) );

-- Factures CREATE TABLE factura ( id UUID PRIMARY KEY, tenant_id UUID NOT NULL, document_id UUID REFERENCES document_pujat(id), numero TEXT, data DATE, import NUMERIC(12,2) NOT NULL, contrapart TEXT, nif_contrapart TEXT );

-- Resultat del matching CREATE TABLE emparellament ( id UUID PRIMARY KEY, tenant_id UUID NOT NULL, moviment_id UUID NOT NULL REFERENCES moviment(id), factura_id UUID NOT NULL REFERENCES factura(id), puntuacio NUMERIC(4,3) NOT NULL, -- 0.000 a 1.000 estat TEXT CHECK (estat IN ('proposat','confirmat','rebutjat')), motiu TEXT, -- 'import_exacte', 'import+referencia', ... creat_el TIMESTAMPTZ DEFAULT now(), UNIQUE (moviment_id, factura_id) ); ```

Decisions:

• `hash_unic` fa la ingesta idempotent: pujar el mateix extracte dues vegades no duplica moviments.
• `puntuacio` separada de `estat`: permet recalcular el matching amb un model millor sense perdre les decisions humanes.
• `motiu` és text lliure però amb valors controlats a l'aplicació; serveix per depurar per què el sistema va proposar un emparellament.

API REST versionada a `/v1`. Autenticació Bearer JWT; el token porta `tenant_id` i el middleware l'injecta a la sessió de Postgres per a RLS.

Endpoints principals:

``` POST /v1/documents (multipart: fitxer, tipus) -> 202 {document_id} GET /v1/documents/{id} -> estat del processament POST /v1/matching/executar -> 202 {job_id} (opcional: filtre per dates) GET /v1/emparellaments?estat=proposat&min_puntuacio=0.7 POST /v1/emparellaments/{id}/confirmar POST /v1/emparellaments/{id}/rebutjar POST /v1/emparellaments/confirmar-en-bloc {ids: [...]} GET /v1/export?format=contaplus&des_de=...&fins_a=... ```

Algorisme de matching (worker):

1. Candidats per import: moviments i factures amb `abs(import)` igual dins de ±0,01 €.
2. Puntuació:

- import exacte: +0,5 - referència de factura present al concepte: +0,35 - contrapart (NIF o nom normalitzat) coincideix: +0,1 - data de factura dins de ±15 dies del moviment: +0,05

1. Llindars: ≥0,85 → `proposat` amb alta confiança; 0,6-0,85 → `proposat`; <0,6 → no es proposa.
2. Un moviment només pot tenir un emparellament `confirmat`; els `proposat` poden ser múltiples.

Motiu dels pesos: l'import és el senyal més fort i barat de calcular; la referència al concepte és el segon, però no sempre hi és. La contrapart i la data refinen sense dominar.

Integracions:

• Exportació ContaPlus: fitxer de text de longitud fixa amb capçalera i línies d'asiento (format documentat per Sage). Motiu: és el que el gestor espera importar directament.
• Exportació A3: CSV amb columnes `fecha, cuenta, debe, haber, concepto`.
• Exportació CSV genèric: per a fulls de càlcul.
• No s'integra amb bancs via PSD2 en la v1. Motiu: el cost de certificació i manteniment d'agregadors (Redsys, Unnax) no es justifica amb un ARPU de 20 €/mes; l'usuari puja l'extracte manualment.

Ordre per valor entregat i risc:

1. Ingesta CSV d'extractes i factures amb `hash_unic` i deduplicació. És el mínim perquè el producte faci alguna cosa.
2. Motor de matching per import + referència amb els pesos de dalt. Sense IA: regles deterministes, fàcils de testejar.
3. UI de revisió: llista d'emparellaments proposats, confirmar/rebutjar en bloc, filtre per puntuació.
4. Exportació CSV genèrica. ContaPlus i A3 després, quan hi hagi clients que ho demanin.
5. Parser de PDF per a 2 bancs (CaixaBank i BBVA), amb plantilles i tests amb extractes anonimitzats.

Fora de l'abast de la v1: PSD2, multi-usuari amb rols, app mòbil, OCR de factures en paper.

Mides: un tenant típic genera 100-300 moviments i 50-150 factures al mes. El matching és O(n·m) sobre candidats filtrats per import, així que en pràctica són desenes de comparacions per moviment. Un worker amb 512 MB de RAM processa un mes en menys de 5 s. Postgres amb 10 GB cobreix centenars de tenants.

Riscos:

• Variabilitat dels extractes PDF: cada banc canvia el format sense avisar. Mitigació: tests de regressió amb extractes reals anonimitzats, i un camí de fallback a CSV sempre visible a la UI.
• Falsos positius en el matching: dos imports iguals el mateix dia (p. ex. dues factures de 50 €) generen ambigüitat. Mitigació: no confirmar automàticament mai; la puntuació baixa si hi ha més d'un candidat amb el mateix import.
• Confiança en les dades: el client pot pujar extractes amb errors. Mitigació: mostrar sempre l'origen (document i línia) al costat de cada moviment.
• Compliment RGPD: dades financeres són sensibles. Mitigació: xifrat en repòs a Postgres i S3, retenció configurable, esborrat per tenant.
• Risc de mercat: el nínxol és competitiu (Holded ja concilia parcialment). Mitigació: enfocar-se en qui NO vol canviar de programa comptable i només vol exportar l'asiento.

1. Tests unitaris del motor de matching amb casos sintètics: import exacte, import + referència, imports duplicats, dates fora de finestra. Cobertura objectiu ≥90 % al mòdul de puntuació.
2. Tests d'integració d'ingesta amb extractes reals anonimitzats de cada banc suportat; el test falla si el parser no extreu el nombre esperat de moviments.
3. Test d'idempotència: pujar el mateix fitxer dues vegades no crea moviments duplicats.
4. Test d'aïllament multi-tenant: un usuari del tenant A no pot llegir cap recurs del tenant B (prova a nivell d'API i de RLS).
5. **