Skip to main content
Un pedido de CAE puede terminar de cuatro formas, y sólo una de las cuatro se reintenta sin pensar. Distinguirlas es la diferencia entre una integración que se recupera sola y una que emite un comprobante fiscal duplicado.

​
Los cuatro desenlaces

​
Qué hacer, en orden

1

Salió autorizado

Listo. Si trae observaciones, leelas y seguí — no son un error.
2

Error de validación (400)

Corregí el pedido. No dejó nada colgado: no se consumió número.
3

ARCA rechazó (422)

Corregí lo que dice details.arca y volvé a emitir. El número se liberó solo.
4

No se sabe qué pasó (409)

Reconciliá. No reintentes. Es el único caso que puede costarte un comprobante duplicado.
5

Error del servidor (500 o 502)

Mirá la lista de comprobantes sin resolver. Si hay algo, reconciliá; si no, reintentá con la misma clave de idempotencia.
La red de seguridad: reintentar con la misma clave de idempotencia nunca duplica. Ante cualquier duda, ése es el movimiento gratis.
Todas las respuestas de esta guía se provocaron y se ejecutaron. Los desenlaces que no se pueden forzar contra ARCA —un corte, una respuesta ilegible— se produjeron contra la frontera falseada, que es el mismo circuito con ARCA sustituido en el último salto.

​
Autorizado con observaciones no es un fallo

ARCA puede aprobar y observar el mismo comprobante. Con CAE y aprobado, el comprobante es válido: la observación es información para tu cliente, no un error tuyo.
El antipatrón concreto: if (respuesta.observations.length) throw. Eso rompe emisiones que ARCA aprobó. El campo que decide es el estado, no la cantidad de observaciones.

​
ARCA rechazó: el número se libera

Cuando ARCA contesta con errores, no hay CAE y el número vuelve a estar disponible.
Un rechazo no deja un hueco. ARCA nunca registró ese comprobante, así que del otro lado el número sigue libre, y Emissa libera el suyo para que coincidan. Verificado: tras un rechazo del número 1, la emisión siguiente —ya corregida— tomó el número 1 otra vez.
Es también la razón por la que un rechazo sí se reintenta: corregí lo que ARCA señaló y volvé a emitir. Lo que no hay que hacer es reintentar sin corregir: el mismo pedido produce el mismo rechazo.
La externalReference de un comprobante rechazado no se puede reusar. El rechazo libera el número, pero el comprobante REJECTED sigue registrado con su referencia: mandarla otra vez devuelve 409 EXTERNAL_REFERENCE_ALREADY_USED. Para reemitir el pedido corregido usá una referencia nueva (la original más un sufijo de intento, por ejemplo) y una Idempotency-Key nueva.

​
Cómo leer el motivo

El mensaje es genérico a propósito; el motivo va en details.arca, con el código y el texto que devolvió ARCA, y viaja también en producción. Leelo siempre: es lo que le dice a tu cliente qué corregir. Es un rechazo fiscal, no una falla de Emissa.
El comprobante rechazado lo guarda con la misma forma (rechazoArca), y el webhook invoice.resolved lo trae cuando el estado final es REJECTED. Los textos son los de ARCA, literales y recortados a 500 caracteres; si errores viene vacío, el motivo está en observaciones. Los códigos son del catálogo de ARCA, no de Emissa. Caen en dos familias:
Muchas de esas combinaciones Emissa las rechaza antes de llegar a ARCA, con un error que no consume número. Las nueve que están medidas una por una viven en por qué hay comprobantes A, B y C.
El comprobante queda registrado como rechazado, y su número liberado:
La correspondencia exacta entre cada número de error y su causa no está verificada acá: se la toma del detalle que ARCA devuelve en cada rechazo.

​
El caso que hay que leer entero: no se sabe qué pasó

Éste es el único que puede costarte un comprobante duplicado. Qué pasó: el pedido salió, y la respuesta no volvió o no se pudo leer. ARCA pudo haber autorizado el comprobante y perderse la confirmación en el camino. Desde afuera, autorizado y no autorizado se ven igual.
Es un 409 y no un 502 a propósito: un 502 invita a reintentar, y acá reintentar es exactamente lo que no hay que hacer.
El comprobante queda registrado con su número tomado, y aparece en la lista de irresueltos:

​
Qué pasa si reintentás a ciegas

Esto se ejecutó. Un comprobante sin resolver, y después un reintento con una clave de idempotencia nueva —que es lo que hace un reintento automático— dejó dos números consumidos y el primero sin resolver.Si ARCA había autorizado el primero —que es precisamente lo que no se sabe— tu cliente acaba de recibir dos comprobantes fiscales por la misma venta. Eso no se borra: se anula con una nota de crédito, y las dos cosas quedan en tu historia y en la de ARCA.
Con la misma clave, en cambio, el reintento es inofensivo:
Por eso la clave se deriva de la intención de facturar y no del intento — ver cómo se numera una serie.

​
Lo que sí hay que hacer: reconciliar

En producción el 409 ARCA_CAE_UNKNOWN no trae details, así que no te dice el id del comprobante. Lo encontrás por externalReference (GET /v1/invoices/search?externalReference=…) o, si no la mandaste, en GET /v1/invoices/unresolved.
Le pregunta a ARCA qué pasó de verdad con ese comprobante y resuelve el estado. Hay dos desenlaces posibles:
No hace nada, y lo dice:

​
Un error del servidor también puede dejar algo sin resolver

Y esto es lo menos evidente de toda la guía. Cuando el servicio de ARCA devuelve un error HTTP que no es SOAP, la respuesta que recibís es genérica —un 500 «Error interno del servidor»— y ese mensaje no te dice lo que necesitás saber: que quedó un comprobante tomando número.
La regla práctica es más amplia que «ojo con el 409»: ante cualquier fallo de la emisión que no sea un error de validación, consultá los comprobantes sin resolver antes de reintentar. Un error por un CUIT mal tipeado no deja nada colgado; un 409, un 500 o un 502 sí pueden.
El camino es el mismo que para el 409 y funciona igual.

​
Qué sigue

Todos los errores

La tabla de consulta, código por código.

Cómo se numera una serie

Por qué el número importa.