Cómo funcionan los sistemas ERP: módulos, flujo de datos y el libro mayor subyacente
Una transacción seguida a través de cada módulo de un ERP, con sus asientos contables reales y el motivo por el cual el libro mayor es el registro que alimenta a todo lo demás.
Un sistema ERP funciona almacenando cada evento empresarial una sola vez, en una base de datos centralizada, y permitiendo que cada módulo lea y escriba en ese registro compartido. Un pedido enviado es exactamente el mismo registro tanto si lo consulta el almacén, el equipo de ventas o el departamento contable. El módulo que mantiene la coherencia en todo el sistema es el libro mayor (general ledger): cada evento con un valor monetario culmina allí en forma de un asiento contable cuadrado, y todos los informes se derivan de dichos asientos.
Este artículo sigue el recorrido de una venta a través de los módulos, muestra los asientos contables que genera y explica por qué la integración con un ERP se centra en los eventos y en el libro mayor en lugar de en las pantallas.
La base de datos compartida
Antes de la llegada de los ERP, cada departamento operaba con su propio programa. Las existencias residían en un sistema de almacén, las facturas en una aplicación de facturación y la contabilidad en un paquete financiero. El cierre de mes se consumía conciliando los tres sistemas. El artículo Qué es el software ERP detalla la categoría; el mecanismo que hace posible su funcionamiento es un modelo de datos unificado en el que:
- un registro de terceros (partner) es utilizado de forma simultánea por ventas, compras y la contabilidad,
- un registro de artículos (item) concentra la cantidad en stock, las capas de coste FIFO (FIFO cost layers), el precio de venta y la cuenta de ingresos,
- un documento (pedido, factura, nota de crédito, compra, orden de producción) hace referencia a los terceros y artículos, generando exactamente un único conjunto de asientos contables,
- un asiento contable (journal entry) apunta al documento que lo originó, de modo que cualquier cifra en un informe se puede rastrear hasta su origen.
Cuando los registros son compartidos, no queda nada que conciliar entre los módulos. Lo único que se debe conciliar es el mundo exterior: los extractos bancarios y las declaraciones fiscales.
El mapa de módulos
| Módulo | Escribe | Lee |
|---|---|---|
| Ventas (Sales) | Pedidos, facturas, notas de crédito | Terceros, artículos, precios, normas de IVA |
| Compras (Purchasing) | Pedidos de compra, facturas de proveedores | Terceros, artículos, cuentas de gastos |
| Inventario (Inventory) | Movimientos de stock, capas de coste FIFO, recuentos físicos | Artículos, almacenes |
| Producción (Production) | Órdenes de producción, consumo de componentes, productos terminados | Listas de materiales (BOM), stock |
| Bancos (Bank) | Transacciones importadas, conciliaciones de pagos | Facturas pendientes, cuentas bancarias |
| Nóminas (Payroll) | Procesamiento de nóminas, cotizaciones, presentaciones | Empleados, contratos, tablas fiscales |
| Activos (Assets) | Registro de activos, ejecuciones de amortización | Grupos de activos, vidas útiles |
| Impuestos (Tax) | Declaraciones de IVA, listas de ventas intracomunitarias, Intrastat, facturas electrónicas | Documentos emitidos y registrados |
| Libro mayor (General ledger) | Asientos contables, cierres de periodo | Todo lo anterior |
| Informes (Reporting) | Nada | El libro mayor y los libros auxiliares |
Todas las filas, salvo las dos últimas, concluyen con una escritura en el libro mayor. Esta es la regla de diseño que distingue a un ERP de un conjunto de herramientas conectadas.
Un flujo de datos práctico
El ejemplo a continuación utiliza los endpoints de Nordlet y las cuentas predeterminadas del plan contable lituano que incluye por defecto. Cualquier ERP ejecuta los mismos pasos, si bien los códigos de cuenta y los nombres de los endpoints varían.
1. Pedido
Una tienda online realiza un pedido mediante POST /v1/ecommerce/orders/create: se especifican un tercero, líneas con artículos y cantidades, y un país de envío. Todavía no se registra nada en el libro mayor. Un pedido representa un compromiso, no una transacción.
2. Reserva de stock
orders/reserve aparta las cantidades correspondientes para impedir que un segundo pedido venda las mismas unidades. Seguimos sin asiento contable: las existencias reservadas continúan siendo de nuestra propiedad.
3. Expedición (Fulfilment)
orders/fulfill registra la salida de la mercancía del almacén. En una única transacción de base de datos se producen dos efectos:
- El stock se consume a coste FIFO: se emplean las capas de coste más antiguas de cada artículo, de acuerdo con el método descrito en la entrada de glosario sobre valoración de inventario FIFO.
- El coste de dichas unidades se contabiliza como un asiento en el que se carga (debe) el coste de las mercancías vendidas y se abona (haber) el stock.
| Cuenta | Debe | Haber |
|---|---|---|
| 6000 Coste de las mercancías vendidas | 600.00 | |
| 2040 Stock | 600.00 |
La expedición genera también una factura en borrador para el pedido y determina el tratamiento de IVA aplicable a partir del país de destino utilizando el motor de IVA de la UE.
4. Emisión de la factura
La emisión de la factura constituye el momento en el que se reconocen los ingresos en una venta puntual (point-in-time sale). El documento recibe su número correlativo sin saltos y se publica un asiento cuadrado: el importe bruto va a clientes, el IVA a la cuenta de IVA repercutido y el importe neto a la cuenta de ingresos.
Para una venta neta de 1.000 € con un tipo de IVA lituano del 21%:
| Cuenta | Debe | Haber |
|---|---|---|
| 2410 Clientes (Cuentas a cobrar) | 1.210.00 | |
| 5000 Ingresos por venta de mercancías | 1.000.00 | |
| 4492 IVA repercutido a pagar | 210.00 |
Si una línea incluye un método de reconocimiento distinto al devengo instantáneo, el importe neto se destina a ingresos diferidos y el motor de reconocimiento de ingresos lo libera según el calendario previsto. El registro de los derechos de cobro y del IVA no sufre alteraciones.
A partir de ese momento, la factura puede expedirse en formato PDF, como factura electrónica Peppol BIS 3.0 o bajo el formato nacional de factura electrónica que exija el país de la empresa.
5. Conciliación bancaria
Dos semanas más tarde se reciben 1.210 €. El movimiento entra a través de una pasarela PSD2 o mediante la importación de un extracto camt.053. El módulo bancario evalúa las facturas candidatas según el importe, la referencia de pago, el nombre de la contraparte y el IBAN, y la llamada bank/transactions/match contabiliza la liquidación:
| Cuenta | Debe | Haber |
|---|---|---|
| 2710 Bancos | 1.210.00 | |
| 2410 Clientes (Cuentas a cobrar) | 1.210.00 |
El estado de la factura pasa a abonada (pagada) y se dispara un webhook sale_invoice.paid. La entrada de glosario sobre conciliación de pagos profundiza en la lógica de emparejamiento. Si el pago se efectúa en otra divisa, en el mismo paso se contabiliza la diferencia de cambio realizada en la cuenta de pérdidas o ganancias.
6. Declaración de IVA
Al cierre del mes no es necesario reintroducir datos de forma manual. La declaración de IVA se calcula a partir de los documentos emitidos y registrados: declarations/eu/vat-return/compute para la declaración nacional (FR0600 en Lituania) y declarations/eu/oss/compute para las ventas transfronterizas a consumidores bajo el régimen de la ventanilla única (OSS). La venta anterior se asigna a la casilla de tipo general de la declaración nacional porque su régimen de IVA es domestic (nacional).
7. Cierre de periodo
Una vez presentada la declaración, ledger/periods/lock efectúa el cierre del mes. A partir de ese instante, cualquier asiento con fecha en dicho periodo, incluidos un apunte bancario tardío o una llamada a la API reintentada, es rechazado con un código HTTP 409. El bloqueo también desencadena el reconocimiento de cualquier ingreso diferido exigible al cierre del periodo, evitando que un mes se cierre con ingresos devengados pendientes en la cuenta de pasivo.
Por qué el libro mayor es el sistema de registro principal
Cada uno de los módulos mencionados gestiona un libro auxiliar (subledger): clientes para cuentas a cobrar, proveedores para cuentas a pagar, artículos para existencias y activos para el inmovilizado. El libro mayor concentra los saldos totales con los que deben cuadrar dichos libros auxiliares. La relación se aborda en Libro auxiliar frente a libro mayor; la consecuencia práctica es que un informe elaborado desde el libro mayor y otro extraído de un libro auxiliar deben arrojar exactamente la misma cifra, y un ERP lo garantiza generando ambos a partir de los mismos asientos contables.
Existen tres propiedades que otorgan al libro mayor la máxima fiabilidad como registro:
- Obligatoriedad del apunte cuadrado. En Nordlet, la base de database rechaza cualquier asiento en el que los débitos no coincidan con los créditos. Un error de programación en un módulo no puede generar un apunte desequilibrado.
- Historial de solo adición (append-only). Un asiento contabilizado jamás se edita. Cualquier error se enmienda mediante un reverso y un nuevo asiento, ambos vinculados al documento original. La entrada sobre el libro mayor inmutable explica por qué los auditores exigen este principio.
- Cierre de periodos. Un mes bloqueado no admite modificaciones, por lo que las cifras presentadas son las que permanecen inalteradas en el sistema.
Integración: eventos e idempotencia frente a procesos por lotes nocturnos
Las integraciones de ERP tradicionales se basaban en ficheros intercambiados durante la noche: exportar pedidos, importarlos y revisar el registro de errores por la mañana. Los ERP modernos exponen una API, de modo que la integración se rige por dos principios fundamentales.
Eventos salientes (Events out). Cuando se produce un cambio, el ERP lo notifica. Nordlet escribe cada evento de webhook en una bandeja de salida (outbox) dentro de la misma transacción de base de datos que el cambio, asegurando que un documento revertido nunca emita un evento y que no se pierda ninguno. Las entregas se firman mediante HMAC-SHA256 y se reintentan aplicando retroceso exponencial (exponential backoff). Su sistema reacciona al evento sale_invoice.paid en lugar de consultar cada cinco minutos si se ha efectuado algún pago.
Reintentos seguros entrantes (Safe retries in). Las redes fallan y una petición reintentada no debe dar lugar a una segunda factura duplicada. Nordlet acepta una cabecera Idempotency-Key en cualquier llamada que modifique datos: la misma clave con idéntica carga útil devuelve la respuesta almacenada; si la clave es la misma pero la carga útil varía, la solicitud es rechazada; además, las claves caducan transcurridas 24 horas. La entrada de glosario sobre idempotencia y el documento de convenciones de la API describen este comportamiento con exactitud.
Dado que cada operación se formula mediante una llamada POST /v1/{module}/{resource}/{action} y la aplicación recurre a los mismos endpoints, una integración puede ejecutar todo el flujo descrito sin que nadie abra una pantalla. El artículo Cómo integrar una API de contabilidad en la nube en una plataforma SaaS detalla el proceso de desarrollo de este tipo de soluciones.
Qué leen los informes
Los informes no almacenan cifras. Consisten en consultas ejecutadas sobre el libro mayor y los auxiliares a una fecha determinada:
- Balance de sumas y saldos, balance de situación, cuenta de pérdidas y ganancias y flujo de efectivo leen los asientos contables agrupados por cuenta y periodo.
- Antigüedad de saldos (Debt aging) lee las cuentas a cobrar y a pagar pendientes según su fecha de vencimiento.
- Saldo y movimientos de stock consultan el subledger de inventario y sus capas FIFO.
- Resumen de IVA procesa las líneas de IVA de los documentos emitidos y registrados.
- Informes por centros de coste leen la dimensión de centro de coste asociada a cada línea de asiento.
En Nordlet, los informes se generan en segundo plano en formatos XLSX, PDF o JSON, y se dispara un webhook cuando el archivo está preparado. Las cifras consolidadas de grupos de empresas proceden de la funcionalidad de consolidación, que combina los libros mayores de varias entidades aplicando ponderaciones de participación y conversión de divisas.
Dónde falla este esquema en la práctica
La mayoría de las incidencias en los ERP se deben a violaciones del principio de registro compartido más que a defectos del software. Los casos más habituales son:
- Una hoja de cálculo paralela destinada a tareas que el ERP "no puede realizar", lo cual provoca discrepancias con la contabilidad oficial.
- Asientos contables manuales empleados para corregir el resultado de un módulo en lugar de rectificar el documento de origen, lo que rompe la trazabilidad desde el informe hasta la fuente.
- Integraciones que vuelcan saldos en lugar de documentos, dejando en el libro mayor totales que nadie es capaz de justificar.
- Periodos abiertos que se mantienen sin bloquear durante meses, permitiendo la alteración de las cifras presentadas en el trimestre anterior.
El artículo Por qué fracasan las implantaciones de ERP analiza cómo se arraigan estos hábitos durante un despliegue, mientras que Cronogramas realistas para la implantación de un ERP muestra en qué fase del proyecto suelen manifestarse.
FAQ
¿Cuál es el núcleo de un sistema ERP?
El libro mayor y el modelo de datos compartido que lo rodea. Cada módulo genera documentos que producen asientos contables cuadrados, y cualquier informe se deriva de dichos asientos.
¿Cómo fluyen los datos a través de un ERP?
Un evento se registra una sola vez en forma de documento (pedido, factura, movimiento, proceso de nómina). El documento genera asientos contables en el libro mayor y movimientos en el libro auxiliar correspondiente. Los informes y las declaraciones fiscales se calculan a partir de esos registros. No se copia información entre módulos.
¿Qué diferencia existe entre un módulo y una integración?
Un módulo escribe en la misma base de datos y en el mismo libro mayor que el resto del sistema. Una integración es un programa externo que se comunica con la API del ERP. En un ERP concebido con la API como eje central (API-first), la distinción es mínima, ya que la integración utiliza los mismos endpoints empleados por los módulos nativos.
¿Registra un ERP los asientos contables de forma automática?
Sí. La emisión de una factura, la expedición de un pedido, la conciliación de un pago, el cálculo de nóminas o la amortización de un activo generan sus respectivos asientos sin necesidad de que un operario deba redactar débitos y créditos. Las cuentas utilizadas proceden de reglas de contabilización configurables por empresa.
¿Por qué los ERP bloquean los periodos contables?
Para evitar que las cifras declaradas o presentadas de un periodo sufran alteraciones posteriores. Un periodo bloqueado rechaza la introducción de nuevos apuntes, lo que protege la pista de auditoría (audit trail) y obliga a canalizar las correcciones hacia el periodo en curso, donde quedan expuestas a la vista de todos.