Cómo Construiría un Sistema de Contabilidad que Oculta el Libro Mayor

Respuesta directa

Un sistema de coordinación contable es una capa que convierte documentos comerciales entrantes en transmisiones aceptadas por myDATA y en un archivo que un contable puede firmar. Un PDF en una bandeja de entrada, una factura de proveedor, una línea bancaria, se convierte en un registro clasificado o en un hueco con nombre propio, no en un chat que “lleva la contabilidad”. Este es un sistema diseñado, no una obra desplegada.

Puntos clave

• El problema del cliente no es teoría contable. Es que los documentos todavía viajan por correo antes de convertirse en contabilidad.
• myDATA ya publica una API REST. Conectar con AADE no es el producto. El producto es el emparejamiento.
• La ley 4308/2014 mantiene a la dirección como responsable del sistema contable. Una herramienta de terceros no les quita esa responsabilidad.

¿Qué problema posee realmente este sistema?

Una pyme griega ya emite y recibe facturas. Alguien sigue fotografiando un recibo en papel, reenviando un PDF, o dejando el extracto de un proveedor en una bandeja de entrada hasta el viernes. El contable abre el archivo, decide qué es, lo teclea en el software, y más tarde descubre que myDATA rechazó la transmisión o que el documento de la contraparte no coincide.

Hoy el camino suele ser este:

1. Los documentos llegan como adjuntos de correo, imágenes de WhatsApp, o una carpeta en un escritorio.
2. Alguien reenvía el montón al contable, a menudo incompleto.
3. El contable clasifica cada línea: ingreso, gasto, tratamiento de IVA, contraparte.
4. El software transmite lo que puede a través de un ERP, un proveedor, timologio, o un formulario.
5. Los rechazos y desajustes vuelven como otro correo.

Nada de eso es la parte difícil de la contabilidad. Es información moviéndose entre una empresa, un proveedor, AADE y un contable, cada uno con una pieza. Esa es la capa de coordinación, y es el producto.

El flujo de trabajo existente que mapearía primero

Antes de cualquier llamada a un modelo, me sentaría con un contable y un cliente y recorrería un mes completo de principio a fin.

Si esa tabla está mal, el sistema está mal. Preferiría pasar una semana en la tabla que un mes en un chatbot que asienta en un libro mayor.

Cómo funcionaría el sistema

Tomemos una factura. Un proveedor envía invoice.pdf. El sistema la lee en campos que una persona puede verificar: nombre del proveedor, AFM, fecha, neto 820 €, IVA 196,80 € al 24% estándar. La empareja con el proveedor que el contable ya tiene fichado, y propone una clasificación a partir de las tablas de designación publicadas, no un plan de cuentas que yo me haya inventado. El contable la acepta o la cambia. Entonces el canal existente transmite.

Si myDATA rechaza el payload, el motivo no se queda en un log. El sistema nombra el hueco. Si RequestDocs muestra después que el proveedor transmitió un neto distinto, pregunta a una persona: ¿los importes no coinciden, pedimos una corrección al proveedor, o lo dejamos para el contable? Una persona decide. Solo entonces, un reintento.

Intake estructurado

Una interfaz breve recoge lo que hace que un documento sea clasificable: archivo, contraparte, fecha, neto e IVA, método de pago. El trabajo del modelo es leer el documento en esos campos y nombrar lo que aún falta. A nadie se le pide elegir un tipo de factura myDATA que no entiende el primer día.

Clasificación

El sistema propone un tratamiento con su razonamiento y su confianza. Las especificaciones técnicas actuales de AADE incluyen un método SendExpensesClassification mejorado y combinaciones de designación publicadas como tablas, no como una suposición. Yo usaría esas combinaciones publicadas como restricción, no inventaría un plan de cuentas que la administración tributaria no reconoce.

Transmisión

Los registros aceptados salen por el canal que la empresa ya tiene: API REST de ERP, un proveedor de facturación electrónica autorizado, o timologio. No montaría un segundo juego de credenciales “porque el agente necesita su propio login”. El registro para la API REST ya es un proceso protegido por Taxisnet en la plataforma myDATA.

Rechazo y gestión de la contraparte

El bucle interesante es el que viene después de SendInvoices. Las especificaciones describen RequestDocs / RequestTransmittedDocs devolviendo información de desviación y rechazo desde la contraparte. Esa es una superficie de producto: mostrar el desajuste, decir qué falta, y esperar a una persona. Un reintento que reenvía ciegamente el mismo payload es la forma de conseguir un error seguro de sí mismo dos veces.

Revisión del contable

El periodo se cierra cuando un contable con nombre y apellido acepta el archivo. El sistema redacta. No se convierte en la contabilidad.

¿Qué se queda bajo control humano?

La ley 4308/2014 es explícita. La dirección es responsable de un sistema contable fiable y de los estados financieros. Usar a un tercero, software o un contable externo, no les exime de eso. Los estados los aprueba el órgano de administración y los firman un miembro autorizado y el contable responsable.

Así que el sistema no:

• elige un tratamiento fiscal que el contable no ha aceptado
• transmite un registro marcado como bloqueado
• firma un periodo
• inventa una posición de IVA porque el modelo está seguro

Autoaprendizaje aquí significa señales de uso, correcciones del contable, y evaluación de la clasificación frente a lo que myDATA realmente aceptó, revisado por una persona. No significa que el sistema cambie en silencio lo que declara.

Cómo mediría el camino

Solo líneas base, antes de construir nada:

• Proporción de documentos entrantes con AFM, fecha e importes legibles a la primera
• Proporción de transmisiones rechazadas, por motivo
• Horas desde la llegada del documento hasta el asiento aceptado
• Proporción de contrapartes donde RequestDocs muestra una desviación que el cliente no había visto

Ninguna afirmación de conversión o de tiempo ahorrado hasta que existan esas cifras.

Cuándo esta es la construcción equivocada

• La contabilidad ya vive en un único ERP que transmite limpio. Entonces estás decorando una tubería que ya funciona.
• El volumen es un puñado de facturas al año. No hay capa de coordinación que absorber.
• Los documentos no llegan digitalmente. Si la entrada es una caja de zapatos, el sistema es un escáner con pasos extra.
• Nadie internamente puede revisar clasificaciones. Sin ese revisor no hay bucle supervisado, solo exposición.
• La ventaja del contable es el criterio en los casos límite, no volver a teclear. Entonces estás construyendo software contra la parte del trabajo que no está en venta.

Cómo conecta esto con el proyecto

Este caso tiene la misma forma que el modelo de cotización a reserva de fletes: un cliente que ya entiende el resultado se ve obligado a aprender el papeleo del sector. La diferencia está en el lado de la oferta. Los transportistas a menudo se niegan a conectarse. AADE ya publicó la interfaz. El cuello de botella se traslada al emparejamiento y a la persona autorizada a firmar, algo más cercano al marcado CE.

El sistema que realmente he construido es el bucle de seguimiento comercial con IA dentro de un CRM. El patrón de rechazo que reutilizaría en las transmisiones está más cerca de el bucle de investigación que sabe cuándo no ejecutarse.

Si esta capa de coordinación ya existe en tu empresa como una carpeta del viernes y la memoria de un contable, el punto de partida operativo es la automatización de flujos de trabajo con IA. Si quieres que lo miren con honestidad, describe el cuello de botella. Si solo quieres el próximo desmontaje, la newsletter basta.

La construcción empieza por el contable, no por la API

La abstracción es una línea: llega un documento, la contabilidad se mantiene consistente con lo que AADE ya tiene. El resultado es una transmisión aceptada y un periodo que un contable firmó. Entre esos dos puntos hay una aburrida capa de coordinación que mueve información entre una empresa, un proveedor, myDATA y una persona que carga con la responsabilidad. Esto es un modelo. Sigue siendo un modelo hasta que un contable que cierra meses reales describa dónde se rompe realmente el emparejamiento.