Cinco empresas del mismo grupo recibían las facturas de sus proveedores por email y las tecleaban a mano, una a una, en el programa de contabilidad. Monté un puente entre su gestor documental y su contabilidad: la factura llega al correo y a partir de ahí nadie la toca hasta que hay que revisarla. Te cuento cómo funciona por dentro, qué decidí mal por el camino y qué hace falta para que algo así funcione en tu empresa.
Casos
PHP, SQL Server, Therefore, Microsoft 365 (Graph), A3, OAuth2, Windows
Cinco sociedades del mismo grupo, cada una con su contabilidad, dedicadas al depósito de contenedores. Y un goteo constante de facturas de proveedores entrando por correo todos los días.
El circuito era el de siempre: abrir el email, guardar el PDF, abrir el programa de contabilidad, teclear el proveedor, el importe, el IVA, la fecha, archivar. Multiplicado por cinco empresas y por cada factura del mes. Nadie se quejaba, porque llevaban años así y era «lo normal». Pero si te paras a mirarlo, alguien estaba copiando a mano datos que ya venían escritos en un papel, para meterlos en un ordenador que tenía ese papel a un metro.
A eso se sumaban los contratos: carpetas llenas de PDFs cuyos vencimientos había que vigilar de memoria. Que es una forma elegante de decir que un día se te pasa uno.
Ya tenían las dos piezas buenas: un gestor documental (Therefore, del ecosistema Canon) donde archivaban todo, y un programa contable (A3) donde llevaban las cinco empresas. Lo que no había era nada en medio. Eso es lo que construí.
La factura llega por email y a partir de ahí no la toca nadie:
Recepción de email (conector Outlook)
-> Archivo automático en Therefore
-> Detección de PDFs multipágina (se separan solos)
-> Validación del proveedor (remitente contra datos maestros)
-> Extracción OCR (NIF, importes, fechas)
-> Normalización (divisas, decimales, fechas)
-> Generación de asientos (Debe/Haber)
-> Registro de IVA (según régimen fiscal)
-> Validación (el total debe cuadrar con las líneas)
-> Exportación a A3 (fichero .DAT)
-> Archivado final
Aquí está la parte que casi nunca se cuenta cuando alguien vende «lectura automática de facturas». Leer el PDF es la parte fácil. Lo difícil es que no todas las facturas se contabilizan igual.
El sistema distingue cinco tipos y cada uno lleva sus propias reglas:
Cuando alguien me pregunta por qué esto no es «instalar un programa que lea facturas», la respuesta es esta lista. La lectura la hace cualquiera. Saber qué hacer con lo leído es el trabajo.
El mismo puente se acabó llevando dos circuitos más, de esos que siempre quedan huérfanos porque no son de nadie:
Un planificador va lanzando tareas independientes a intervalos cortos: sincronizar maestros, separar multipágina, validar, normalizar, contabilizar, exportar.
La decisión importante fue esa, que cada tarea vaya por libre. Si una etapa se atasca, las demás siguen trabajando. Un pipeline en el que todo depende de que el paso anterior termine bien es un pipeline que se para entero el día que un proveedor manda un PDF raro.
| Tarea | Cada | Qué hace |
|---|---|---|
| Sincronización de maestros | 2 min | Proveedores y cuentas de gasto al día |
| Separación multipágina | 30 s | Un PDF con tres facturas → tres documentos |
| Validación y normalización | 20-30 s | Proveedor, divisa, decimales, fechas |
| Contabilización | 30 s | Asientos Debe/Haber + registro de IVA |
| Exportación | 30 s | Fichero .DAT validado, listo para A3 |
Antes de exportar nada, cada factura tiene que pasar tres controles: que el total coincida con la suma de sus líneas, que el IVA sea uno de los tipos admitidos y que la codificación sea la que el programa contable espera recibir.
Lo que no cuadra no se exporta. Se queda señalado, esperando a que lo mire una persona.
Esa es, para mí, la única forma honesta de automatizar contabilidad: el sistema hace solo lo que es seguro y pregunta lo dudoso. Un automatismo que se inventa un número para no parar es mucho peor que un proceso manual, porque el error entra en los libros con aspecto de dato bueno.
Una de esas cosas que no aparecen en ningún manual y que descubres a base de mirar. El gestor documental no guarda los PDFs sueltos en una carpeta: los mete en unos ficheros propios que en realidad son ZIP con otro nombre.
Y para saber en qué subcarpeta está cada uno hay que hacer una cuenta: se coge el número del documento, se convierte a base 36 y la subcarpeta son sus dos últimos dígitos. Es decir, que para leer un PDF hay que reimplementar la aritmética interna del programa de otro.
Lo cuento porque es un buen ejemplo de dónde se va de verdad el tiempo en una integración. No en la parte que suena difícil, sino en averiguar cómo piensa el sistema con el que te toca hablar.
La aplicación se ejecuta en Windows, en la misma máquina que el gestor documental, porque necesita ver directamente las carpetas donde este deja sus ficheros. Un contenedor no llega ahí.
Podría haberlo forzado. Habría quedado más moderno en esta ficha. Pero habría añadido una capa de complicación a cambio de nada, y el que se la come cuando algo falla un martes por la mañana es el cliente. La herramienta correcta no siempre es la más nueva.
Lo que sí hice fue empaquetar todo el entorno (servidor web, PHP y utilidades) en un instalador que deja la máquina lista en ocho pasos guiados, y comprueba al final que llega a la base de datos y a las carpetas. Si un día hay que montarlo otra vez, se monta en una tarde y no es una aventura arqueológica.
Por honestidad, que una ficha sin huecos confesados es un folleto:
Las facturas dejaron de teclearse. El contable del grupo pasó de copiar datos a revisar excepciones, que es a lo que debería dedicarse un contable. Los contratos avisan solos antes de vencer. Y cinco sociedades que hacían cinco veces el mismo trabajo comparten hoy un único circuito.
Nada de esto es inteligencia artificial ni nada espectacular. Es fontanería: conectar dos programas que ya estaban comprados y que llevaban años dándose la espalda.
¿En tu empresa se sigue tecleando lo que ya viene escrito, o vigilando vencimientos de memoria? Escribí una guía sobre cómo elegir un software de gestión documental, y si quieres que miremos tu caso, cuéntamelo aquí.
Sí, y suele ser de los proyectos más rentables que hay, porque las dos piezas caras ya están compradas y lo que falta es el trozo de en medio. El gestor documental archiva la factura que llega por email, un proceso lee los datos, decide el asiento y genera el fichero que el programa contable importa. En este caso el puente une Therefore con A3, pero el planteamiento vale para cualquier pareja de programas que permita leer sus datos y aceptar una importación.
No se contabiliza. Antes de exportar nada, cada factura pasa tres controles: que el total cuadre con la suma de sus líneas, que el IVA sea uno de los tipos admitidos y que la codificación sea la que espera el programa contable. Lo que no cuadra se queda marcado para que lo mire una persona. Es la única forma honesta de automatizar contabilidad: hacer solo lo seguro y preguntar lo dudoso, porque un dato inventado entra en los libros con aspecto de dato bueno.
Es justo el caso para el que se montó. Aquí son cinco sociedades del mismo grupo, cada una con su plan contable y sus cuentas, compartiendo un único circuito de entrada. La factura no sabe de qué empresa es hasta que el sistema mira el proveedor y el destinatario, y a partir de ahí aplica las reglas de esa sociedad. Cinco contabilidades al final, un solo flujo por delante.
Tres cosas, y ninguna es comprar más software. Un gestor documental que deje leer sus datos, un programa de contabilidad que admita importar apuntes, y sobre todo tener claras las reglas: qué tipos de factura recibes y cómo se contabiliza cada uno. Esa tercera es la que de verdad cuesta y la que decide si el proyecto sale bien, porque automatizar un criterio que nadie ha escrito nunca es lo que convierte estos proyectos en un pozo.