Condición de IVA del receptor: el campo que puede trabarte la facturación

Por Juan Schmid | 2026-09-16 | 9 min de lectura

Hay un campo de la factura electrónica que hasta ahora ARCA dejaba pasar y que está por dejar de perdonar: la condición frente al IVA de tu cliente. Si tu sistema no lo manda, el pedido de CAE empieza a volver rechazado — y sin CAE no hay factura.

No es una novedad de esta semana: la obligación viene de la RG 5616/2024 y rige desde abril de 2025. Lo que cambia es que ARCA detectó que muchísimos comprobantes se siguen emitiendo sin el dato, y anunció que va a dejar de ser tolerante. Esta nota es la parte operativa que no encontré escrita en ningún lado: la tabla completa de códigos y cómo verificar, hoy, si tu sistema lo está mandando.

Lo que tenés que saber, en 30 segundos

• La obligación ya existe. La RG 5616/2024 se publicó en el Boletín Oficial el 18 de diciembre de 2024 y rige desde el 15 de abril de 2025.
• Lo que cambia es la tolerancia. Según lo publicado por la prensa especializada, a partir del 1 de diciembre de 2026 ARCA rechaza automáticamente el pedido de CAE que no traiga el código. El plazo de adecuación va hasta el 30 de noviembre.
• No alcanza con tenerlo en tu base. El dato tiene que viajar en el campo técnico del web service (CondicionIVAReceptorId). Que figure en la ficha del cliente, o impreso en el PDF, no cuenta.
• Pega distinto según con qué factures. Si usás el portal de ARCA, ya te lo pide en pantalla. Si usás un sistema propio o de un tercero conectado por web service, ahí es donde hay que mirar.

Qué es la condición de IVA del receptor

Es la caracterización fiscal de quien te compra, respecto de esa operación puntual: si es responsable inscripto, monotributista, consumidor final, exento, y así. Hasta la RG 5616 el dato viajaba de forma indirecta — se deducía de la letra del comprobante y del tipo de documento. Ahora se informa de manera explícita, con un código propio.

El motivo es el Libro de IVA Digital: al etiquetar el comprobante en el momento de emitirlo, ARCA se ahorra tener que inferir después de qué tipo de operación se trató. Para vos el efecto práctico es uno solo: un campo más que tu sistema tiene que completar bien, en cada comprobante.

La tabla de códigos, completa

Estos son los valores que devuelve el método FEParamGetCondicionIvaReceptor del web service de facturación. No están inventados ni copiados de otra nota: son los que SpomBridge le manda a ARCA en cada comprobante.

Los códigos 2, 3, 11, 12 y 14 no están: corresponden a categorías derogadas o que ARCA no acepta como receptor. Si tu sistema todavía guarda Responsable No Inscripto, es una categoría que ya no existe y hay que mapearla.

Ojo con un detalle: no todos los códigos son válidos con cualquier letra. La combinación tiene que cerrar — un consumidor final no puede recibir una factura A. Si tu sistema deja elegir las dos cosas por separado y no las valida entre sí, ese es el lugar donde te va a saltar el rechazo.

Cómo saber si tu sistema ya lo manda

Esta es la parte que importa y la que nadie contesta. Tres formas, de la más fácil a la más técnica:

1. Mirá una factura que ya emitiste. Si el PDF muestra la condición frente al IVA del cliente junto a su CUIT, es buena señal, pero no es prueba: el PDF lo arma tu sistema, no ARCA. Sirve para descartar el caso peor — si ni siquiera lo imprime, casi seguro tampoco lo manda.
2. Cruzá contra "Mis Comprobantes" en ARCA. Entrá con tu clave fiscal y abrí el detalle de un comprobante emitido. Si ARCA muestra la condición de IVA del receptor, es porque tu sistema se la informó. Esta sí es prueba, porque el dato lo está mostrando ARCA y no vos.
3. Preguntale a quien te hizo el sistema. La pregunta exacta, para que no haya vueltas: "¿el pedido de CAE incluye el campo CondicionIVAReceptorId en FECAEDetRequest?". Es sí o no. Si la respuesta es "está en la base de datos" o "sale en el PDF", la respuesta es no.

Si el campo no viaja, el web service devuelve un error de campo obligatorio o de valor inválido sobre CondicionIVAReceptorId — en las comunidades de desarrolladores se lo referencia como el error 10242. El comprobante no se autoriza: no es una advertencia que podés ignorar.

Cuál código va en cada caso

La regla corta, que cubre el 95% del comercio:

• Si el que emite es monotributista, siempre emite factura C, sin importar quién le compre. Igual tiene que informar la condición del receptor.
• Si el que emite es responsable inscripto, la condición del receptor decide la letra: un RI recibe A (código 1); un consumidor final (5), un monotributista (6) o un exento (4) reciben B.
• Venta al exterior: cliente del exterior (9), con comprobante de exportación.

Si querés repasar cómo se elige la letra y qué comprobante corresponde en cada caso, está en la guía de factura electrónica. Y si todavía estás decidiendo tu propia categoría, la comparación entre monotributo y responsable inscripto arranca por ahí.

Los tres errores que vemos más seguido

1. Mandar "Consumidor Final" para todo. Es el atajo tentador porque nunca hace saltar un error de letra. Pero si tu cliente es RI y necesita el crédito fiscal, le estás emitiendo una B cuando correspondía una A, y el problema se lo trasladás a él.
2. Dejar clientes viejos sin condición cargada. Las bases migradas suelen tener el campo vacío en la mitad de los registros. Mientras ARCA fue tolerante, no pasaba nada. Conviene revisarlo antes de diciembre y no cuando no puedas facturar.
3. Tener la condición en la ficha del cliente y no mandarla. Es el caso más frustrante porque el dato existe: lo que falta es que el sistema lo mande en el campo del web service. Es el que más se parece a "ya está resuelto" sin estarlo.

Si facturás con SpomBridge

No tenés que hacer nada. SpomBridge informa la condición de IVA del receptor en cada pedido de CAE desde antes de que ARCA empezara a exigirlo, y valida que la combinación de condición y letra cierre antes de mandar el comprobante.

El número, para no dejarlo en una promesa: entre el 10 de marzo y el 15 de septiembre de 2026 se autorizaron 2.133 comprobantes con CAE llevando ese campo, sin un solo rechazo de ARCA por ese motivo. No lo decimos porque lo leímos en una resolución: lo decimos porque son los comprobantes que emitieron nuestros clientes.

Si venís de otro sistema y no sabés si el tuyo lo manda, el punto 2 de más arriba te lo contesta en cinco minutos y no requiere que nos escribas.

Qué está confirmado y qué no

Esto es contenido fiscal, así que corresponde separar una cosa de la otra:

• Confirmado: la RG 5616/2024 existe, se publicó en el Boletín Oficial el 18 de diciembre de 2024 y rige desde el 15 de abril de 2025.
• Confirmado: los códigos de la tabla son los que acepta el web service de ARCA hoy. Están verificados contra comprobantes reales con CAE otorgado.
• Reportado por la prensa, no verificado por nosotros contra el Boletín Oficial: que el rechazo automático arranca el 1 de diciembre de 2026 y que el plazo de adecuación vence el 30 de noviembre. Lo publicaron El Cronista, iProfesional y varios medios especializados en impuestos durante septiembre de 2026.

Si la fecha exacta es lo que define tu plan de trabajo, confirmala con tu contador o en el sitio de ARCA antes de agendarla. Lo que no depende de la fecha es la conclusión: el campo es obligatorio desde 2025 y conviene que tu sistema lo mande.

En resumen

La condición de IVA del receptor es un campo chico con una consecuencia grande: sin él, en algún momento dejás de poder facturar. La obligación no es nueva; lo que se termina es la tolerancia. Y la mayoría de los que van a tener el problema hoy no lo saben, porque sus comprobantes se siguen autorizando igual.

Cinco minutos en "Mis Comprobantes" te sacan la duda. Si el dato está, no tenés nada que hacer. Si no está, tenés hasta fin de noviembre — que parece lejos y no lo es, porque del otro lado hay alguien que te tiene que tocar el sistema.