Qué fecha usa cada reporte (transaction_date vs created_at)
Explicación de cuál fecha usa cada reporte y listado en contable.io. Por qué la fecha contable de la transacción nunca coincide con la fecha de creación del registro.
Actualizado: 5 de abril de 2026
Cada transacción contable en contable.io tiene dos fechas distintas, y entender cuándo se usa cada una evita confusiones al conciliar reportes.
Las dos fechas
| Campo | Significado |
|---|---|
transaction_date | La fecha contable del hecho económico. Es la que el usuario captura en la factura, recibo o comprobante. Determina en qué período fiscal cae la transacción. |
created_at | La fecha del sistema en la que se grabó el registro en la base de datos. Es automática, inmutable, y sirve para auditoría. |
Ejemplo: una factura de compra con fecha 2026-03-15 que se registra en el sistema el 2026-04-02 tiene
transaction_date = 2026-03-15ycreated_at = 2026-04-02.
Por qué importa
Si un reporte usa la fecha equivocada, puede:
- Excluir transacciones que pertenecen al período (registradas tarde).
- Incluir transacciones de períodos anteriores (registradas hoy pero con fecha contable vieja).
- Mostrar saldos diferentes según cuándo ejecutas el reporte sobre los mismos datos.
Regla del proyecto (vigente desde 2026-03-29)
TODOS los reportes y listados financieros usan transaction_date, NUNCA created_at.
Esto incluye:
- Balance de prueba.
- Estados financieros (Balance General, P&L).
- Libro mayor y libro diario.
- Auxiliares.
- Cartera por edades.
- Listado de facturas, recibos, comprobantes.
- Reportes de impuestos (declaraciones IVA, ReteFuente).
created_at solo se usa en:
- Auditoría (quién registró qué cuándo).
- Logs de actividad (timeline de cambios).
- Reportes operativos (productividad del equipo, ej: “facturas registradas hoy”).
Ejemplo concreto
Imagina este escenario:
| Acción | transaction_date | created_at |
|---|---|---|
| Factura de venta a Cliente A | 2026-03-31 | 2026-04-02 |
| Factura de venta a Cliente B | 2026-04-01 | 2026-04-01 |
Al generar el P&L de marzo 2026:
- ✅ Correcto (
transaction_date): incluye la factura de Cliente A, excluye la de Cliente B. - ❌ Incorrecto (
created_at): excluye la de Cliente A (creada en abril), incluye la de Cliente B.
¿Por qué esto fue un cambio?
Antes del 2026-03-29, algunos listados usaban created_at por simplicidad técnica. Esto causaba problemas al cerrar un mes:
- Si registrabas el día 2 una factura del mes anterior, no aparecía en el P&L del mes correcto.
- Los balances cambiaban si recargabas el reporte después de registrar una factura atrasada.
La estandarización fuerza a TODOS los queries a filtrar por transaction_date, garantizando que el cierre de un período no cambia retroactivamente, incluso si llegas tarde a registrar transacciones.
Implicaciones para el usuario
- Captura siempre la fecha real de la transacción al crear facturas y comprobantes — esa es la que cuenta para tus reportes y declaraciones DIAN.
- Si registras transacciones de meses anteriores, asegúrate de no haber cerrado el período (períodos cerrados no aceptan nuevos asientos).
- La fecha de creación queda como histórico de auditoría, no como dato fiscal.
Reportes de productividad operativa
Si necesitas un reporte de “cuántas facturas se registraron en el sistema esta semana” (independientemente de su fecha contable), úsalo desde Configuración → Reportes operativos → Actividad de usuarios. Esos sí usan created_at porque la pregunta es operativa, no contable.