> ## 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.

# Por qué hay comprobantes A, B y C

> La condición frente al IVA del emisor y la del receptor deciden el tipo. Elegir mal es un rechazo.

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.](https://mintcdn.com/emissa/4QpgM24I6Fz3ej59/images/diagramas/letra-del-comprobante.light.svg?fit=max\&auto=format\&n=4QpgM24I6Fz3ej59\&q=85\&s=2843285f3ceb6b6220d83b570a13c2a8)

![](https://mintcdn.com/emissa/4QpgM24I6Fz3ej59/images/diagramas/letra-del-comprobante.dark.svg?fit=max\&auto=format\&n=4QpgM24I6Fz3ej59\&q=85\&s=e342fe4348454cb393b211c0acff2ded)

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:

| Letra | La emite | Se la das a | ¿Discrimina IVA? |
| - | - | - | - |
| **A** | Responsable inscripto | Responsable inscripto | Sí |
| **B** | Responsable inscripto | Cualquier otro (consumidor final, monotributista, exento) | No |
| **C** | Monotributista o exento | Cualquiera | No, nunca |

> [!NOTE]
>
> **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.

> [!WARNING]
>
> **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.

> [accordion] Factura A a un consumidor final
>
> Una A necesita que el receptor esté identificado. Sin identificar no hay a
> quién discriminarle el IVA.
>
> ```json theme={null}
> {
>   "errorCode": "INCOMPATIBLE_INVOICE_TYPE",
>   "message": "El tipo de comprobante no corresponde al emisor o al receptor",
>   "details": "un comprobante A necesita un receptor identificado con CUIT (DocTipo 80)"
> }
> ```

> [accordion] Factura A a alguien con CUIT que no es responsable inscripto
>
> Tener CUIT no alcanza: un monotributista tiene CUIT y le corresponde B.
>
> ```json theme={null}
> {
>   "errorCode": "INCOMPATIBLE_INVOICE_TYPE",
>   "details": "un comprobante A se emite a un responsable inscripto; para otras condiciones corresponde B"
> }
> ```

> [accordion] Factura B a un responsable inscripto
>
> **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.
>
> ```json theme={null}
> {
>   "errorCode": "INCOMPATIBLE_INVOICE_TYPE",
>   "details": "a un responsable inscripto le corresponde un comprobante A, no B"
> }
> ```

> [accordion] Factura C emitida por un responsable inscripto
>
> ```json theme={null}
> {
>   "errorCode": "INCOMPATIBLE_INVOICE_TYPE",
>   "details": "un \"Responsable Inscripto\" no emite comprobantes C: le corresponde A o B"
> }
> ```

> [accordion] Factura A emitida por un monotributista
>
> ```json theme={null}
> {
>   "errorCode": "INCOMPATIBLE_INVOICE_TYPE",
>   "details": "un \"Monotributista\" no emite comprobantes A: le corresponde C"
> }
> ```

> [accordion] Factura C con IVA discriminado
>
> É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**.
>
> ```json theme={null}
> {
>   "errorCode": "INCOMPATIBLE_INVOICE_TYPE",
>   "details": "un comprobante C no discrimina IVA: todas las lineas gravadas tienen que ir con alicuota 0% (Id 3), o exentas / no gravadas"
> }
> ```

> [accordion] Factura A sin razón social de verdad
>
> 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.
>
> ```json theme={null}
> {
>   "errorCode": "MISSING_RECEIVER_BUSINESS_NAME",
>   "message": "Un comprobante A necesita la razón social del receptor"
> }
> ```

## 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.

> [accordion] La emisión completa, como la devuelve la API
>
> ```json theme={null}
> {
>   "cbteTipoNombre": "FACTURA_A",
>   "letra": "A",
>   "comprobante": "0001-00000003",
>   "receiver": {
>     "docTipo": 80,
>     "docNro": "30500001735",
>     "name": "Cliente Mayorista SA",
>     "vatConditionNombre": "IVA_RESPONSABLE_INSCRIPTO"
>   },
>   "totals": {
>     "netAmount": "1000.00",
>     "vatAmount": "210.00",
>     "totalAmount": "1210.00"
>   },
>   "status": "AUTHORIZED",
>   "cae": "86300696854515",
>   "arcaMetadata": { "resultado": "A", "authorized": true, "observaciones": 1 }
> }
> ```
>
> 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](https://www.emissa.com.ar/docs/guias/conceptos-fiscales.md).

> [accordion] Los códigos que van en la API
>
> El tipo de comprobante es un número del catálogo de ARCA:
>
> | Código | Comprobante |
> | - | - |
> | `1` | Factura A |
> | `6` | Factura B |
> | `11` | Factura C |
> | `8` | Nota de crédito B |
>
> 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:
>
> | Id | Condición |
> | - | - |
> | `1` | IVA responsable inscripto |
> | `4` | IVA sujeto exento |
> | `5` | Consumidor final |
> | `6` | Responsable monotributo |

## Sobre consultar el padrón de ARCA

> [!WARNING]
>
> **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.

> [!WARNING]
>
> **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.

> [accordion] Cómo se ve esa respuesta hoy
>
> ```json theme={null}
> {
>   "documentNumber": "30500001735",
>   "name": "Cliente Mayorista SA",
>   "vatCondition": "IVA_RESPONSABLE_INSCRIPTO",
>   "padronStatus": "NOT_FOUND",
>   "padronMessage": "El padron de ARCA no reconoce 30500001735: soap:Server: No es posible calcular el id AT",
>   "padron": null
> }
> ```
>
> `30500001735` es un CUIT válido y pasa el dígito verificador: el `NOT_FOUND` es
> de la consulta, no del contribuyente.

## Qué sigue

> [card] [Cómo se numera una serie](https://www.emissa.com.ar/docs/guias/numeracion.md)
>
> Por qué un hueco en la numeración importa.

> [card] [Cuando el CAE viene rechazado](https://www.emissa.com.ar/docs/guias/cae-rechazado.md)
>
> Los rechazos que sí vienen de ARCA.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.