Skip to main content
La letra no la elegís. La deciden dos datos: tu condición frente al IVA y la de tu cliente. Elegir mal es el rechazo más común de cualquier integración argentina, y es el único que puede dejarte la serie con un hueco.

​
Qué letra te toca

Si sos responsable inscripto emitís A a un cliente responsable inscripto, y B a cualquier otro. Si sos monotributista o exento, emitís C siempre.

Dos preguntas y ya sabés la letra

​
Por qué es así

En Argentina el IVA no siempre se discrimina en el comprobante. Discriminarlo —mostrar el neto y el impuesto por separado— sólo tiene sentido si el que recibe la factura puede computárselo como crédito fiscal. Si no puede, el IVA va adentro del precio y no se muestra. De ahí salen las tres letras:
Si sos monotributista no tenés que decidir nada: emitís C siempre. Es el error conceptual más frecuente de quien viene de otro país, buscar «cuál es el equivalente de la Factura A para monotributistas». No hay. La C es el comprobante del monotributista.

​
Cómo evitar el rechazo antes de mandarlo

Lo que Emissa no puede adivinar es la condición frente al IVA de tu cliente.
1

Preguntásela

Si tu producto le pide el CUIT, pedile también la condición: es un campo más en un formulario que ya existe, y es el único dato que decide la letra. Cuatro opciones alcanzan para casi todos los casos — consumidor final, responsable inscripto, monotributista, exento.
2

Si no la tenés, emitile B

Es lo que corresponde a quien no está inscripto, y es la opción segura: emitir B a un responsable inscripto está mal, pero es un error que la API te devuelve antes de consumir un número de la serie.
No deduzcas la condición del prefijo del CUIT. Un 30 es una persona jurídica, y una persona jurídica puede ser responsable inscripto, exenta o monotributista.

​
Emissa valida antes de hablar con ARCA

Y eso importa más de lo que parece: un rechazo de ARCA consume el número de comprobante, y un rechazo de Emissa no. Todas las combinaciones mal armadas se frenan acá, sin costo.
Una A necesita que el receptor esté identificado. Sin identificar no hay a quién discriminarle el IVA.
Tener CUIT no alcanza: un monotributista tiene CUIT y le corresponde B.
El error va en las dos direcciones. No es que «A sea más exigente que B»: a un responsable inscripto le corresponde A, y emitirle B también está mal.
Éste es el que más cuesta entender viniendo de afuera. Un monotributista emite C y sus líneas van con alícuota 0 %, no con 21 %. No es que el IVA esté incluido y oculto: en la C no hay IVA que discriminar.
Un A se imprime a nombre de alguien que va a computarse el crédito fiscal, así que la razón social es obligatoria.Y lo que se bloquea no es el nombre vacío —eso ya lo atrapa la validación de campo— sino el nombre fabricado: Cliente <CUIT> es el marcador que genera un sistema cuando no sabe el nombre, y llegaba a imprimirse como razón social. Un placeholder que atraviesa la cadena y sale por la impresora es peor que un error, porque parece un dato.

​
La que sí sale

Con el emisor responsable inscripto y el receptor responsable inscripto identificado con CUIT, la A se autoriza. El IVA aparece discriminado —neto $1.000, IVA $210— porque es una A. En la B esos mismos $1.210 se informan igual a ARCA, pero el comprobante impreso no los separa.
Fijate observaciones: 1: esta A quedó autorizada y observada a la vez. Que eso no es un fallo está explicado en CUIT, CAE y homologación.
El tipo de comprobante es un número del catálogo de ARCA:Las notas de crédito siguen la letra de lo que anulan: una Factura B se anula con una nota de crédito B. Emissa elige el tipo por vos al anular.Y la condición del receptor se declara aparte — obligatorio desde la RG 5616:

​
Sobre consultar el padrón de ARCA

Hoy la consulta al padrón no está habilitada, porque el certificado tiene que estar delegado a ese servicio en WSASS y es un trámite aparte del de facturación. El alta del cliente funciona igual —los datos son los que declarás— pero el resultado del padrón viene vacío.
Con una key test el padrón que se consulta es el de homologación, no el real. Un CUIT real, y válido, puede devolver NOT_FOUND (o no resolver) porque el padrón de pruebas de ARCA no lo tiene cargado. No es un error de tu pedido ni una caída: es el ambiente. Con una key live se consulta el padrón de producción. En GET /v1/arca/padron/{cuit} el ambiente sale del modo de la key y se puede forzar con ?environment=; en POST /v1/customers/validate-tax sale del ambiente del contribuyente.
Dos cosas que conviene saber antes de apoyarte en él:
  • No resuelve la condición: te la pide. La condición frente al IVA es un campo obligatorio del pedido. El endpoint valida y guarda al cliente; no es una búsqueda que devuelva qué es un CUIT.
  • Un «no encontrado» no significa que el CUIT no exista. Significa que la consulta no se pudo hacer. Mientras el trámite de delegación esté pendiente, no uses ese estado para decidir si un cliente es real.
30500001735 es un CUIT válido y pasa el dígito verificador: el NOT_FOUND es de la consulta, no del contribuyente.

​
Qué sigue

Cómo se numera una serie

Por qué un hueco en la numeración importa.

Cuando el CAE viene rechazado

Los rechazos que sí vienen de ARCA.