Contabilidad de Matriz, propuesta técnica

Héctor: esto es lo que hay que programar para el segundo módulo de Matriz, el de contabilidad. Lee los bancos de una empresa, recoge sus facturas, propone a qué factura corresponde cada movimiento y deja la contabilidad lista para su ERP o para su gestoría; en una fase posterior emite facturas con Verifactu. Se instala por cliente, con varias sociedades dentro, y se conecta con MailDraft.

Alcance

El módulo cubre la contabilidad del día a día de una empresa de 20 a 200 personas. No presenta impuestos ni lleva almacén.

Cada empresa trabaja en uno de dos modos. Con ERP: su ERP sigue siendo el sistema fiscal, y el módulo concilia, prepara y le pasa asientos. Sin ERP: el módulo lleva el libro y emite las facturas.

El orden de las fases y los pilotos están propuestos, sin cerrar. Los dos clientes piloto van aquí sin nombre, como A y B.

Cómo se entrega. Una instalación por cliente, con su base de datos y su contrato de Enable Banking, y varias sociedades dentro. Se cobra una cuota al mes. El mismo código se usa solo o como sección de la plataforma que el cliente ya tiene.

Queda fuera:

• presentar modelos fiscales (303, 111, 115, 347, 349), el SII y las cuentas anuales: los presenta la gestoría con las cifras que le da el módulo;
• almacén, pedidos, albaranes y circuitos de venta;
• calcular nóminas: solo se importa su resumen mensual;
• ordenar pagos o remesas desde el módulo: el banco es de solo lectura;
• TicketBAI, IGIC, recargo de equivalencia y cuentas en otra moneda;
• otros ERP (Sage, Holded, Odoo): entran después, por la misma puerta que a3ERP.

Conectividad

El módulo habla con ocho sistemas y solo escribe fuera en tres: el ERP, la AEAT y el correo, donde deja borradores.

A la izquierda, lo que entra; a la derecha, lo que sale; abajo, los dos servicios en los que se apoya. Las flechas con dos puntas son conexiones de ida y vuelta.

Bancos: Enable Banking

• Autenticación. Cada llamada lleva un JWT RS256 de una hora firmado con la clave privada de la aplicación: kid es el id de la aplicación, iss es enablebanking.com y aud, api.enablebanking.com.
• Flujo. GET /aspsps?country=ES da los bancos; se enseñan los que admiten psu_type: business. POST /auth con el banco, valid_until, un state de un solo uso y la dirección de vuelta devuelve la URL del banco. El usuario autoriza allí y vuelve con un code. POST /sessions lo cambia por la sesión y sus cuentas. Después, GET /accounts/{uid}/balances y GET /accounts/{uid}/transactions, paginado con continuation_key.
• Consentimiento. Dura lo que diga maximum_consent_validity de cada banco: 180 días en la mayoría. Un 401 o un 403 al leer significa sesión caducada. Renovar es volver a autorizar, y tiene que conservar la cuenta y sus movimientos.
• Histórico. En la hora siguiente a la autorización la mayoría de los bancos dan un año o más; después, muchos limitan a 90 días. La primera lectura pide todo.
• Límite. Sin el usuario delante, muchos bancos admiten unas cuatro consultas al día (429, ASPSP_RATE_LIMIT_EXCEEDED). Leer saldo y movimientos de una cuenta gasta dos.
• Una sola vez. Cada movimiento se identifica por entry_reference o transaction_id. Si faltan, por una huella de fecha, importe, concepto e IBAN. Solo se guardan los movimientos firmes (BOOK).
• Producción. La aplicación se activa con contrato y revisión de la empresa, o en modo restringido enlazando las cuentas propias. Pide política de privacidad, condiciones y un correo de protección de datos. Cobra por volumen, con un mínimo al mes que no publica.
• Visto en el cliente A. CaixaBank, Bankinter, Banca March e Ibercaja conectan. Una cuenta de BBVA falla con «Error interacting with ASPSP». Santander y Sabadell, que pasan por Redsys, no dejan entrar al usuario de empresa. Para esos, extracto.

Extractos: Norma 43

• Texto de ancho fijo en Windows-1252. Registros 11 (cabecera de cuenta), 22 (movimiento), 23 (conceptos), 33 (final de cuenta) y 88. Fechas AAMMDD; la clave 1 es un cargo.
• Se comprueba que el saldo inicial más los movimientos da el final. Si no, no se carga.
• La cuenta se localiza por entidad, oficina y número.
• Un movimiento que ya entró por Enable Banking no puede entrar otra vez por el extracto: hace falta una identidad común a las dos vías. En lo que hay hecho no existe.

Correo: MailDraft

Es el contrato entre los dos módulos. La forma es una propuesta para cerrarla contigo.

Sin MailDraft, el módulo tiene su propio buzón de facturas: una dirección a la que reenviar.

ERP: a3ERP

• API. Un servicio de Windows en el servidor del cliente; pide a3ERP 14 o posterior y el diccionario JNCAPI. POST /api/login con un usuario de a3ERP devuelve un token.
• Qué ofrece. Maestros en /api/maestro/{clientes, proveedores, cuentas, bancos, formaspago}. Facturas en /api/documento/{tipo}. Asientos: GET /api/asientos y POST /api/asientos/crear, con fecha, tipo, diario y los apuntes (cuenta, debe y haber). Cobrar y pagar vencimientos en /api/cartera/cobrar y /api/cartera/pagar.
• Solo se añade. La API también modifica y borra. El adaptador no tiene esas operaciones.
• Destino explícito. Primero, la empresa de pruebas, que es una copia de la real dentro de a3ERP. Se asienta el mismo periodo a mano y con el módulo, y hasta que no dan lo mismo no se apunta a la real.
• Sin duplicar. Cada asiento lleva la referencia del módulo, y el módulo guarda el identificador que devuelve a3ERP.
• Por fichero. Para quien no tenga la API: SUENLACE.DAT, registros de 512 bytes en Windows-1252 (tipo 0, apunte; 1 y 2, factura y rectificativa; 9, detalle de IVA; C, alta de cuenta). Lo importa el a3 de la gestoría, no a3ERP.
• Sin confirmar. De quién es esa API (Wolters Kluwer o un distribuidor), qué cuesta y cómo se llega al servidor del cliente sin abrirle puertos. Lo natural sería un agente local que llame hacia fuera.

AEAT: Verifactu

• Por cada factura, un registro de alta, y uno de anulación si se anula, con huella SHA-256 encadenada al registro anterior.
• En el modo VERI*FACTU el registro se envía a la AEAT al expedir. La factura lleva el código QR y la leyenda.
• Una factura expedida no se edita ni se borra: se rectifica o se anula.
• El productor del programa firma una declaración responsable, visible dentro de la aplicación.
• Calendario. En el BOE, el uso obliga a las sociedades desde el 1 de enero de 2027 y al resto desde el 1 de julio de 2027. Hacienda anunció en octubre que lo llevaría a octubre de 2028; a primeros de noviembre no estaba publicado. Las obligaciones del productor ya están en vigor.

Plataforma del cliente

• El módulo expone su propia API, documentada, para todo lo que hace su interfaz.
• La plataforma de un cliente lo monta como una sección: acceso único, enlaces a cada pantalla y sus propias dimensiones de análisis (centro, proyecto, barco o puerto).
• Avisos de salida para quien quiera reaccionar: factura confirmada, movimiento conciliado, mes cerrado.

Funcionalidades

Son doce áreas. Cada una tiene una regla que no se rompe, y esa regla es lo primero que hay que respetar al programarla.

El detalle, requisito a requisito y con su identificador, está en Requisitos.

Cómo propone el cruce

Es el corazón del módulo. Así funciona lo que ya está en producción en el cliente A:

1. Candidatas: las facturas contabilizadas con saldo pendiente, del mismo signo que el movimiento.
2. Importe exacto, al céntimo: 50 puntos.
3. Señal del proveedor, solo la mejor: el IBAN de la contraparte es el de su ficha (40), su NIF está en el concepto (35) o está su nombre (25).
4. El número de la factura aparece en el concepto: 30.
5. El pago cae a cinco días o menos del vencimiento: 10. A más de 120 días: se restan 15.
6. Si ninguna llega a 75, se buscan combinaciones de facturas del mismo proveedor que sumen el importe exacto.
7. Se enseñan las cinco mejores. La primera es «clara» si tiene 50 puntos o más y 20 de ventaja sobre la segunda.

Por añadir: los cobros de clientes, un margen para céntimos y comisiones, los traspasos entre cuentas propias y las liquidaciones agrupadas.

Automatizaciones

El módulo hace solo todo lo que no decide nada: leer, reconocer, proponer y avisar. Contabilizar y enviar lo confirma una persona, salvo lo que cada empresa ponga en automático.

Cuánto se hace solo lo elige cada empresa. Hay dos niveles:

1. Proponer. Es el que viene puesto. Nada se confirma sin una persona.
2. Confirmar lo inequívoco. Se confirma sin preguntar el cruce que coincide en importe exacto y, además, en IBAN o en número de factura. Coincidir solo en importe no basta.

Todo lo que se hizo solo se distingue en pantalla, queda en el registro de actividad y se puede deshacer mientras el mes esté abierto.

La IA tiene interruptor por empresa, límite de gasto al mes y registro del coste de cada llamada. Con la IA apagada, todo lo demás funciona.

Datos y reglas del sistema

El modelo ya está probado en producción con una sola empresa; lo que falta es ponerle empresa a todo.

Lo que vale para todo el sistema:

• la empresa va en cada tabla y en cada consulta;
• importes en céntimos enteros y porcentajes en puntos básicos (2100 es el 21 %);
• fechas contables sin hora;
• códigos de cuenta y de tercero como texto: en a3ERP hay proveedores «A160»;
• cada asiento se puede seguir hasta su movimiento, su factura y su documento, y al revés;
• el registro de actividad no se modifica ni se borra, tampoco desde la base de datos;
• las sesiones del banco y las claves van cifradas; la clave privada de Enable Banking, solo en el entorno del servidor;
• documentos y registros se conservan seis años;
• verificación en dos pasos para dirección y contabilidad.

Pruebas. La lógica contable va en funciones puras, sin base de datos: Norma 43, cruce, asientos, validación de facturas, SUENLACE y Verifactu. En el portal del cliente A hay unas 95 comprobaciones de este tipo que valen como casos.

Lo que ya existe

Casi toda la fase 1 está programada y en uso en el portal del cliente A, para una sola empresa y con sus datos metidos en el código. Es TypeScript (Next.js y Prisma): vale como referencia de algoritmos y de casos de prueba, se programe en lo que se programe.

Lo que no existe en ningún sitio: la empresa en las tablas, los cobros y las facturas emitidas en el cruce, una identidad de movimiento común a la conexión y al extracto, la escritura en a3ERP y Verifactu.

Interfaz. La dirección elegida es Mesa: un inicio que resume lo pendiente y lo reparte en tareas, con los movimientos en bandeja o en tabla. La maqueta programada, con datos ficticios, está en matriz.concretoabstracto.com.

Por cerrar

Seis decisiones son para verlas contigo y cuatro datos dependen de terceros.

Contigo:

• Pila y repositorio: ¿dentro de MailDraft (Python, FastAPI y PostgreSQL) o como un servicio aparte? La referencia que existe es TypeScript.
• Instalación por cliente: una base de datos por cliente, con varias sociedades dentro. ¿Cómo encaja con el despliegue de MailDraft?
• Lo que puede dar ya el backend de MailDraft: avisar de un adjunto nuevo, consultar los hilos de una dirección, crear un borrador y un inicio de sesión común.
• Quién figura ante la AEAT como productor del programa de facturación y firma la declaración responsable.
• Qué modelo de IA lee las facturas, y con qué contrato de encargo del tratamiento.
• Reparto y estimación: quién hace la interfaz y quién el resto, y cuánto lleva cada fase.

Sin confirmar, con terceros:

• Enable Banking: el mínimo mensual, el precio por cuenta y si un contrato vale para las instalaciones de varios clientes.
• a3ERP: de quién es la API, qué cuesta, qué versión tiene el cliente B y cómo se llega a su servidor.
• Verifactu: si el aplazamiento a octubre de 2028 llega al BOE.
• El orden de las fases y los pilotos.

Fuentes

Consultadas el 14 de noviembre de 2026.

• Enable Banking: preguntas frecuentes y panel de control. De ahí salen la activación en producción, el modo restringido, el histórico y los límites.
• a3ERP: documentación de la API REST, con sus páginas de maestros, documentos, asientos y cartera, y la guía del conector de Chift.
• Verifactu: Real Decreto 1007/2023, texto consolidado, con última actualización del 3 de diciembre de 2025, y la nota de SuperContable del 9 de octubre de 2026 sobre el aplazamiento anunciado.
• El código y los documentos de los proyectos de los clientes A y B, y la interfaz de MailDraft.