> ## Documentation Index > Fetch the complete documentation index at: https://www.emissa.com.ar/docs/llms.txt > Use this file to discover all available pages before exploring further. # Qué hacer cuando el CAE viene rechazado > Los cuatro desenlaces de un pedido de CAE, y por qué sólo uno se reintenta sin pensar. 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é pasó | ¿Hay CAE? | ¿El número quedó tomado? | ¿Reintentar? | | - | - | - | - | | **Autorizado** | Sí | Sí | No hace falta | | **Autorizado con observaciones** | Sí | Sí | **No.** El comprobante vale | | **ARCA rechazó** | No | **No, se liberó** | Sí, corrigiendo el pedido | | **No se sabe** | **No se sabe** | **Sí** | **Nunca a ciegas** | ## 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. > [!TIP] > > **La red de seguridad:** reintentar con la misma clave de idempotencia nunca > duplica. Ante cualquier duda, ése es el movimiento gratis. > [!NOTE] > > 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. > [!WARNING] > > **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. > [accordion] Una emisión aprobada y observada, real > > ``` > HTTP 201 · status=AUTHORIZED · cae=70001000000001 > observations=[ > { > "code": 10217, > "message": "El credito fiscal discriminado en el presente comprobante solo podra ser computado a efectos del Procedimiento permanente de transicion al Regimen General." > } > ] > arcaMetadata={"service":"wsfev1","resultado":"A","authorized":true,"observaciones":1} > ``` ## ARCA rechazó: el número se libera Cuando ARCA contesta con errores, no hay CAE y **el número vuelve a estar disponible**. > [!NOTE] > > **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. > [!WARNING] > > **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. ```json theme={null} "details": { "arca": { "errores": [{ "codigo": 10016, "mensaje": "El campo DocNro es incorrecto." }], "observaciones": [] } } ``` 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: | Familia | Qué son | Qué hacer | | - | - | - | | **Se arreglan corrigiendo el pedido** | Combinaciones de tipo, documento del receptor e importes que no cierran | Corregir y reemitir | | **Hablan de la serie** | El número enviado no es el que ARCA esperaba | Ver [cómo se numera una serie](https://www.emissa.com.ar/docs/guias/numeracion.md) | > [!TIP] > > **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](https://www.emissa.com.ar/docs/guias/tipos-de-comprobante.md). > [accordion] Cómo se ve un rechazo de ARCA > > ```json theme={null} > { > "statusCode": 422, > "errorCode": "ARCA_WSFEV1_REJECTED", > "message": "ARCA rechazó el comprobante" > } > ``` > > El comprobante queda registrado como rechazado, y su número liberado: > > ``` > filas tras el rechazo: [{"number":1,"status":"REJECTED","cae":null}] > la emision siguiente tomo el numero 1 (status 201) > ``` > > 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**. > [!NOTE] > > 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: ```bash theme={null} curl "https://api.emissa.com.ar/v1/invoices/unresolved?taxpayerId=TU_TAXPAYER_ID" \ -H "X-API-Key: $EMISSA_API_KEY" ``` ### Qué pasa si reintentás a ciegas > [!WARNING] > > 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. > [accordion] La corrida completa > > ``` > intento 1: HTTP 409 ARCA_CAE_UNKNOWN > intento 2 (clave NUEVA): HTTP 201 numero=2 cae=70001000000002 > > la serie quedo asi: > [ > { "number": 1, "status": "UNKNOWN", "cae": null }, > { "number": 2, "status": "AUTHORIZED", "cae": "70001000000002" } > ] > > comprobantes en total: 2 > ``` > > Con la **misma** clave, en cambio, el reintento es inofensivo: > > ``` > reintento con la MISMA clave: HTTP 201 Idempotent-Replay=true numero=2 > ``` > > Por eso la clave se deriva de la intención de facturar y no del intento — ver > [cómo se numera una serie](https://www.emissa.com.ar/docs/guias/numeracion.md). ### 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`. ```bash theme={null} curl -X POST https://api.emissa.com.ar/v1/invoices/{id}/reconcile \ -H "X-API-Key: $EMISSA_API_KEY" ``` Le pregunta a ARCA qué pasó de verdad con ese comprobante y resuelve el estado. Hay dos desenlaces posibles: | ARCA contesta | Qué le pasa al comprobante | Qué hacés | | - | - | - | | **Lo tenía autorizado** | Pasa a autorizado, con su CAE | Nada. **No emitas de nuevo** | | **No lo tiene** | Pasa a rechazado y su número se libera | Recién ahí podés volver a emitir | > [accordion] Si el comprobante ya estaba resuelto > > No hace nada, y lo dice: > > ```json theme={null} > { > "statusCode": 409, > "errorCode": "INVOICE_NOTHING_TO_RECONCILE", > "message": "El comprobante ya tiene un estado definitivo" > } > ``` ## 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. > [!WARNING] > > **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. > [accordion] El camino de recuperación, ejecutado > > ``` > filas: [{"number":1,"status":"PENDING"}] > unresolved tras el 500: HTTP 200 · 1 comprobante(s) · [{"comprobante":"0001-00000001","status":"PENDING"}] > reconcile tras el 500: HTTP 200 status=REJECTED cae=null > ``` > > El camino es el mismo que para el `409` y funciona igual. ## Qué sigue > [card] [Todos los errores](https://www.emissa.com.ar/docs/guias/errores.md) > > La tabla de consulta, código por código. > [card] [Cómo se numera una serie](https://www.emissa.com.ar/docs/guias/numeracion.md) > > Por qué el número importa. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.