En esta nota (8 secciones)
"Que facture" es una línea en un pliego y suele estar cotizada como una funcionalidad más, al lado de "listado de clientes". No lo es. Integrar un sistema con ARCA —el organismo que reemplazó a la AFIP— es la parte del proyecto con más reglas ajenas, más estados intermedios y menos margen de error, porque el que valida no sos vos.
Esto es lo que hay adentro, para que puedas evaluar un presupuesto y saber qué preguntar.
Qué significa "facturar electrónicamente"
Tu sistema no emite la factura. Pide permiso para emitirla.
El circuito es: armás el comprobante, se lo mandás a un web service del organismo, y esperás. Si todo cierra, te devuelve un CAE —Código de Autorización Electrónico— con su fecha de vencimiento. Recién con ese CAE el comprobante es válido. Sin CAE no hay factura: hay un borrador.
Esa distinción es la que ordena todo el diseño. Tu sistema tiene que poder convivir con comprobantes en tres estados: armados pero no enviados, enviados sin respuesta, y autorizados. El segundo es el que arruina las integraciones hechas a las apuradas.
Las tres piezas que hay que resolver
Autenticación
No se entra con usuario y contraseña. Se entra con un certificado digital X.509 y su clave privada.
El flujo: tu sistema firma un pedido con el certificado, lo manda al servicio de autenticación, y recibe un ticket de acceso con vigencia acotada —del orden de las doce horas—. Ese ticket se usa para todo lo demás hasta que vence, y ahí se renueva.
Tres cosas que hay que hacer bien acá:
- Cachear el ticket. Pedir uno nuevo en cada factura es la forma más rápida de que te empiecen a rechazar pedidos por abuso.
- Renovarlo solo, antes de que venza. Si esto no está resuelto, el sistema deja de facturar a las doce horas y nadie entiende por qué.
- Guardar la clave privada como el secreto que es. No en el repositorio, no en el código, no en una variable a la vista. Con ese archivo se factura a nombre de la empresa.
El certificado además hay que tramitarlo y delegar el permiso del servicio en el administrador de relaciones con clave fiscal. Es trámite del contribuyente, no del desarrollador, y es el motivo más común de demora al arrancar. Conviene empezarlo el primer día del proyecto, no la semana antes de salir.
El comprobante
Acá está la mayor parte del trabajo real, y casi nada es técnico: es fiscal.
Hay que resolver qué tipo de comprobante corresponde —A, B, C, notas de crédito y débito—, y eso depende del cruce entre tu condición frente al IVA y la del cliente. Un monotributista emite C; un responsable inscripto emite A o B según a quién le venda. Esa lógica vive en tu sistema y tiene que estar bien, porque el organismo valida algunas cosas pero no todas.
Después está el detalle que rompe presupuestos: la numeración es correlativa por punto de venta y no puede tener huecos. Si el comprobante 105 se autorizó y el 106 falló, el 107 no se puede emitir antes de resolver el 106. Un sistema que numera antes de tener el CAE se desincroniza el primer día de uso real.
Y las fechas: hay ventanas de tolerancia entre la fecha del comprobante y la fecha de autorización, distintas según se trate de productos o servicios. Facturar el lunes algo fechado del mes pasado no siempre se puede.
Los errores
Una integración que sólo contempla el camino feliz no está terminada.
- Rechazos. El organismo devuelve códigos de error. Algunos son de datos —un CUIT mal, un total que no cuadra con los impuestos— y se corrigen. Otros son de configuración y no.
- Observaciones. El comprobante se autoriza igual pero con una advertencia. Hay que registrarla, no descartarla.
- Timeouts. El peor caso: mandaste el comprobante y no sabés si se autorizó. Nunca reintentes a ciegas, porque podés duplicar. Lo correcto es consultar el último comprobante autorizado de ese punto de venta y recién ahí decidir.
- Servicio caído. Pasa, y pasa en fin de mes. El sistema tiene que poder encolar y reintentar después sin que la operación se frene.
La diferencia entre una integración de dos semanas y una de dos días está casi toda acá. El camino feliz es rápido; lo que lleva tiempo es todo lo que puede salir mal.
Homologación no es producción
Existe un ambiente de pruebas separado, con su propio certificado. Es imprescindible y también es engañoso: es más permisivo que el real, y responde más rápido.
Presupuestá una etapa de pruebas en producción, con comprobantes reales de monto bajo, antes de dar la integración por terminada. Es la única forma de descubrir las validaciones que el ambiente de pruebas no aplica.
Qué preguntar cuando te cotizan esto
- ¿Qué tipos de comprobante entran? ¿Notas de crédito y débito están incluidas o son aparte?
- ¿Cómo se maneja un timeout sin duplicar el comprobante?
- ¿Dónde se guarda la clave privada del certificado?
- ¿La renovación del ticket es automática?
- ¿Está contemplado el reintento cuando el servicio no responde?
- ¿Incluye pruebas en producción o sólo en homologación?
- Cuando el organismo cambia una versión con fecha límite, ¿quién lo actualiza y con qué costo?
La última es la que más plata define a largo plazo. Estas APIs cambian por decisión del organismo y en su calendario. Una integración sin mantenimiento previsto funciona hasta que deja de funcionar, y esa fecha no la elegís vos.
Cuándo no integrar
Vale la pena decirlo: no siempre conviene.
Si facturás poco volumen y con comprobantes simples, el portal web del organismo es gratis y funciona. Si ya tenés un sistema contable que factura bien, quizás lo que necesitás es que tu sistema le pase los datos a ese, no que aprenda a facturar por su cuenta.
La integración se justifica cuando el comprobante es la última pieza de un circuito que ya está en tu sistema —el pedido, el remito, la cuenta corriente— y cargarlo a mano en otro lado significa duplicar trabajo y abrir la puerta a que los números no coincidan.
Si ese circuito todavía no está, empezá por ahí. Facturar es el final del proceso, no el principio.
Las reglas y validaciones fiscales cambian. Verificá contra la documentación oficial vigente y con tu contador antes de tomar decisiones sobre este tema.