Por qué hay comprobantes A, B y C

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.

Toda respuesta de error de esta guía se ejecutó contra la API. Son textuales.

La letra sale del IVA, no del monto

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:

Leído al revés, que es como se usa: primero mirá qué sos vos —eso descarta letras— y después a quién le facturás —eso elige entre las que quedan.

Si sos responsable inscripto

Emitís A o B, y decide tu cliente:

• Cliente responsable inscripto → A. Le discriminás el IVA porque se lo computa.
• Cliente consumidor final, monotributista o exento → B. El IVA va en el precio.

Si sos monotributista o exento

Emitís C siempre, a cualquiera. Un monotributista no discrimina IVA —no lo cobra por separado— así que no hay decisión que tomar: no existen las letras A y B para vos.

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.

Los códigos que van en la API

cbteTipo 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 cuando llamás a POST /v1/invoices/{id}/cancel.

Y receiverVatConditionId declara la condición del receptor — obligatorio desde la RG 5616:

Qué devuelve la API cuando la letra no corresponde

Emissa valida las combinaciones antes de hablar con ARCA. Eso importa: un rechazo de ARCA consume el número de comprobante, y un rechazo de Emissa no. Todos estos son 400, sin costo:

Factura A a un consumidor final

{
  "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)"
}

Una A necesita que el receptor esté identificado. Con receiverDocTipo: 99 —consumidor final sin identificar— no hay a quién discriminarle el IVA.

Factura A a alguien identificado pero que no es responsable inscripto

{
  "errorCode": "INCOMPATIBLE_INVOICE_TYPE",
  "details": "un comprobante A se emite a un responsable inscripto; para otras condiciones corresponde B"
}

Tener CUIT no alcanza: un monotributista tiene CUIT y le corresponde B.

Factura B a un responsable inscripto

{
  "errorCode": "INCOMPATIBLE_INVOICE_TYPE",
  "details": "a un responsable inscripto le corresponde un comprobante A, no B"
}

El error va en las dos direcciones. No es "A es más exigente que B": a un responsable inscripto le corresponde A, y emitirle B también está mal.

Factura C emitida por un responsable inscripto

{
  "errorCode": "INCOMPATIBLE_INVOICE_TYPE",
  "details": "un \"Responsable Inscripto\" no emite comprobantes C: le corresponde A o B"
}

Factura A emitida por un monotributista

{
  "errorCode": "INCOMPATIBLE_INVOICE_TYPE",
  "details": "un \"Monotributista\" no emite comprobantes A: le corresponde C"
}

Factura C con IVA discriminado

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

Éste es el que más cuesta entender viniendo de afuera. Un monotributista emite C y sus líneas van con alícuota 0 % (vatRateId: 3), no con 21 %. No es que el IVA esté incluido y oculto: en la C no hay IVA que discriminar.

Factura A sin razón social de verdad

{
  "errorCode": "MISSING_RECEIVER_BUSINESS_NAME",
  "message": "Un comprobante A necesita la razón social del receptor",
  "details": "\"Cliente 30500001735\" no es una razon social: es el marcador que se pone cuando no se conoce el nombre..."
}

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. Emisión real:

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

El IVA aparece discriminado —netAmount 1000, vatAmount 210— porque es una A. En la B esos mismos $1.210 se informan igual a ARCA, pero el comprobante impreso no los separa.

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

Cómo evitar el rechazo antes de mandarlo

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

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

Y si no lo 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 en 400 antes de consumir un número de la serie.

Lo que no conviene es deducir 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.

Sobre consultar el padrón de ARCA

POST /v1/customers/validate-tax da de alta un cliente y contrasta los datos contra el padrón de ARCA. Dos cosas que conviene saber antes de apoyarte en él:

• No resuelve la condición: te la pide. vatCondition es un campo obligatorio del pedido. El endpoint valida y guarda al cliente; no es una búsqueda que devuelva qué es un CUIT.
• 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 bloque padron viene en 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
}

Ese NOT_FOUND no significa que el CUIT no exista —30500001735 es válido y pasa el dígito verificador—: significa que la consulta no se pudo hacer. Mientras el trámite de delegación esté pendiente, no uses padronStatus para decidir si un cliente es real.

Qué sigue

• Cómo se numera una serie — por qué un hueco importa.
• Qué hacer cuando el CAE viene rechazado — los rechazos que sí vienen de ARCA.