ARCA 5852/2026: CAEA, plazo y contingencia con registro
La prórroga de CAEA da 61 días para ordenar facturación: cola local, puntos de venta, rendición diferida, permisos y prueba de caída antes del 1 de agosto.
ARCA movió el cambio de CAEA al 1 de agosto y dejó una tarea incómoda para facturación. En una bodega exportadora de Luján de Cuyo, el encargado de logística sufre cada caída del WebService porque el despacho sale igual y la factura queda esperando. La Resolución General 5852/2026 entra para ordenar esa contingencia; esta nota explica qué guardar, quién aprueba y cómo probar la salida antes del corte.
Qué cambió para facturación electrónica
La Resolución General 5852/2026 fue publicada el 29 de mayo de 2026 y cambió la fecha de vigencia de las reglas 5782 y 5785 al 1 de agosto. Ese movimiento da 61 días entre la publicación y el nuevo corte. La norma también dice que desde el 1 de junio queda habilitado el uso de CAEA como modalidad complementaria de contingencia sin tramitar una nueva adhesión.
La cifra que corrige la rutina está en la RG 4290: la contingencia con CAEA medida por sucursal tiene un techo del 5% del lapso mensual de disponibilidad de servicios de la administración. La caída deja de ser una anécdota del sistema y pasa a ser un dato que alguien debe medir por punto de venta, fecha, comprobante y causa.
El punto de venta queda bajo prueba.
La referencia técnica ayuda a elegir la pila. Stack Overflow 2024 registró PostgreSQL con 48,7% de uso entre desarrolladores y lo ubicó como la base más usada por segundo año. Para una pyme argentina, esa adopción global importa porque reduce el riesgo de depender de una herramienta rara para guardar comprobantes, estados y auditoría.
La prórroga no borra la urgencia operativa. La adelgaza en tareas concretas: revisar certificados, confirmar puntos de venta, medir caídas, separar comprobantes pendientes y dejar una bitácora por cada intento. Un sistema que solo muestra “error de conexión” obliga a reconstruir la historia a mano; un registro bien armado muestra hora, causa, usuario y siguiente paso.
Cómo funciona por dentro
El flujo empieza en el sistema de ventas o ERP. El usuario carga la operación, el punto de venta, el cliente, el tipo de comprobante y el importe. La aplicación intenta pedir CAE al WebService de ARCA; si falla por conectividad o servicio, abre una cola local de contingencia con estado pendiente, responsable y motivo.
PostgreSQL guarda registros estructurados: factura, CUIT, punto de venta, CAEA asignado, estado de envío, fecha de generación y usuario que aprobó. MinIO o un almacenamiento S3 guarda PDF, XML o constancia si la empresa conserva adjuntos pesados. La cola envía la rendición cuando vuelve el servicio y deja el resultado de cada intento.
El permiso separa tres acciones. Ventas puede cargar y ver su comprobante. Administración puede aprobar la salida de contingencia y corregir un dato antes de rendir. Sistemas puede ver errores técnicos, certificados y logs, pero queda fuera de la edición comercial. El backup copia base y adjuntos; la prueba restaura un comprobante real, recalcula el estado y muestra si la rendición sigue pendiente o confirmada.
Qué se instala o configura primero
La pila mínima tiene un módulo de facturación del ERP, PostgreSQL 17 o 18 para registros, un job de reintento, almacenamiento S3 para constancias y un tablero simple de pendientes. En un servidor chico, 2 vCPU, 4 GB de RAM y disco respaldado alcanzan para una sucursal; el costo mensual ronda USD 18 a 35, entre ARS 25.740 y ARS 50.050 al dólar vendedor de ARS 1.430. El costo excluye horas de adaptación del ERP y soporte fiscal.
El primer entregable verificable es una operación de prueba con tres estados: CAE emitido, CAEA usado por contingencia y rendición aceptada. UMSA suele pedir que esa prueba quede escrita con hora, usuario, punto de venta y captura del resultado, porque el antagonista real no es ARCA sino la factura manual qué aparece dos semanas después sin dueño ni causa.
La implementación toma de una a tres semanas si el ERP ya emite por WebService. En sistemas con planillas auxiliares, el primer paso es listar todos los puntos de venta y cerrar los que nadie administra. Recién ahí conviene agregar reintentos, alertas y backup.
Dónde se rompe y cómo probarlo
El primer riesgo es duplicar comprobantes. La señal aparece cuando dos filas tienen mismo punto de venta, tipo, número e importe con estados distintos. La prueba es bloquear la clave única y forzar dos reintentos simultáneos desde usuarios diferentes.
El segundo riesgo es rendir tarde. La señal es una cola con pendientes viejos y sin responsable. La prueba es cortar el acceso al WebService, emitir por contingencia, restaurar la conexión y medir cuánto tarda el job en informar cada comprobante.
El tercer riesgo es perder evidencia. La señal aparece cuando el PDF existe, pero la base perdió el estado o el usuario. La prueba de backup restaura base y adjuntos en otro servidor y compara cinco comprobantes contra el tablero.
Si el tablero no muestra pendientes por punto de venta, la contingencia quedó ciega.