CUIT, CAE y homologación

Cuatro palabras que aparecen en cada respuesta de la API y que nadie explica porque en Argentina se dan por sabidas. Si no sos argentino —o sos argentino y no contador— esto es lo que hace falta para tomar decisiones correctas contra la API en vez de descubrirlas cuando ARCA rechaza.

Quién es ARCA

El organismo que recauda los impuestos nacionales. Hasta 2024 se llamaba AFIP, y el nombre viejo sigue vivo en todas partes: los servidores con los que Emissa habla son wsaahomo.afip.gov.ar y wswhomo.afip.gov.ar. Si ves "AFIP" en un log, es el mismo organismo.

Lo que importa para integrar: ARCA autoriza los comprobantes de uno en uno, antes de que se los entregues a tu cliente. No es un régimen de declaración mensual. Cada factura pasa por un webservice y vuelve con un número de autorización, o vuelve rechazada.

CUIT

La Clave Única de Identificación Tributaria: 11 dígitos que identifican a un contribuyente. Es lo que en otros países sería el número de identificación fiscal.

30-50000173-5
│    │       └── dígito verificador
│    └────────── cuerpo, 8 dígitos
└─────────────── prefijo: 20/23/24/27 personas físicas, 30/33/34 jurídicas

El último dígito es aritmética, no un dato. Sale de un módulo 11 sobre los otros diez, así que un CUIT mal tipeado se puede detectar sin consultar nada. Emissa lo verifica antes de hablar con ARCA:

{
  "statusCode": 400,
  "errorCode": "INVALID_RECEIVER_DOCUMENT",
  "message": "El documento del receptor no es válido para su tipo",
  "details": "el digito verificador no corresponde"
}

Esa respuesta es de 30500001736 — el CUIT válido 30500001735 con el último dígito cambiado.

Por qué la validación importa más de lo que parece. Un CUIT mal tipeado que llega a ARCA es un rechazo con el número de comprobante ya consumido: la serie queda con un hueco que después hay que explicar. Atajarlo antes es gratis; atajarlo después no se puede.

Emissa no valida el prefijo, a propósito: la lista que se publica no es estable —ARCA suma rangos— y una lista incompleta rechazaría contribuyentes reales. El verificador sí, porque es aritmética.

El CUIT no es el único documento

En el receptor podés mandar cuatro tipos:

Punto de venta

El "mostrador" desde el que emitís. No es un lugar físico: es una numeración independiente que ARCA te habilita. La factura 0001-00000131 es el punto de venta 0001, comprobante 131.

Tiene su propia guía porque hay un alta que hacer antes de poder emitir — Qué es un punto de venta.

CAE

El Código de Autorización Electrónico: catorce dígitos con los que ARCA dice "esta factura existe y la autorizo yo". Sin CAE, lo que tenés no es un comprobante fiscal: es un PDF.

De una emisión real de esta documentación:

{
  "status": "AUTHORIZED",
  "cae": "86300696854515",
  "caeExpiresAt": "2026-08-08",
  "arcaMetadata": { "resultado": "A", "authorized": true, "observaciones": 1 }
}

resultado: "A" es ARCA diciendo aprobado. El CAE lo emitió el organismo, no Emissa.

Por qué el CAE tiene fecha de vencimiento

caeExpiresAt no lo calcula Emissa: es el campo CAEFchVto que devuelve ARCA, y se guarda tal cual. En la emisión de arriba, autorizada el 2026-07-29, ARCA puso vencimiento 2026-08-08 — diez días.

Lo que ese plazo acota, por normativa de ARCA, es la entrega del comprobante al receptor: no es que la factura deje de existir el 9 de agosto. Dicho de otro modo, no podés guardarte un CAE para usarlo más tarde. Por eso el CAE se pide cuando facturás y no antes.

(La fecha y su duración están medidas; qué obliga el plazo es normativa de ARCA, no comportamiento de esta API. Si tu caso depende de eso, consultalo con tu contador.)

Consecuencia práctica para tu integración: no encoles emisiones por días. Si tu sistema factura en lotes, el lote tiene que emitir contra ARCA, no reservar autorizaciones.

Autorizado no es lo mismo que sin observaciones

Esto sorprende a casi todos, y la emisión de arriba lo muestra: es una Factura A autorizada —resultado: "A", con CAE— y observada:

{
  "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."
    }
  ]
}

ARCA tiene tres desenlaces, no dos:

No trates una observación como un fallo. Si tu código hace if (observations.length) throw, vas a romper emisiones que ARCA aprobó. El campo que decide es status / resultado, no la longitud del arreglo.

Homologación

El ambiente de pruebas de ARCA. Es un juego completo de servidores paralelo al productivo:

Lo importante, y es lo que lo distingue de un sandbox cualquiera: homologación entrega CAE real. Los CAE de esta documentación —86300696854515 y los de el quickstart— salieron de los servidores de ARCA. No es un simulador ni un mock: la firma, el sobre SOAP y la respuesta son los mismos que en producción.

Lo que no es: un ambiente con validez fiscal. Un comprobante de homologación no le sirve a tu cliente y no entra en ninguna declaración. Sirve para que tu integración esté terminada antes de tocar la serie real.

Los comprobantes de homologación consumen números de su propia serie y no se devuelven. Es un detalle sin consecuencias —la serie es de prueba— pero explica por qué el número no arranca en 1 cuando empezás.

En Emissa, el ambiente es un campo del contribuyente (environment), y la clave que uses tiene que coincidir: una clave emi_test_ contra un contribuyente en PRODUCCION da 403 API_KEY_WRONG_MODE. El quickstart cierra con los tres controles del paso a producción, medidos.

Qué sigue

• Qué es un punto de venta — el alta que hay que hacer en ARCA antes de emitir.
• Por qué hay comprobantes A, B y C — la decisión que más rechazos causa.