Equivalencia de campos con ARCA

Esta página responde dos preguntas: cómo se llama en ARCA cada campo de la API, y cuándo es obligatorio según el comprobante que emitas y quién sea tu receptor.

Si venís de una integración directa contra ARCA, es el diccionario que necesitás para traducir lo que ya tenías.

Qué comprobante te corresponde

Lo determina tu condición fiscal como emisor:

Tu condición fiscal	Comprobantes que emitís	Cuándo
Responsable Monotributo	C — 11 12 13	Siempre, a cualquier receptor
IVA Sujeto Exento	C — 11 12 13	Siempre, a cualquier receptor
IVA Responsable Inscripto	A — 1 2 3	Si el receptor es Responsable Inscripto o Monotributista
	B — 6 7 8	Si el receptor es consumidor final o exento

Es la regla que más consultas genera: si sos monotributista emitís C y no discriminás IVA, sin importar a quién le factures. Ver Tipos de comprobante.

Matriz de obligatoriedad

● obligatorio · ◐ condicional · ○ se acepta pero se ignora

Campo (NanoFactura)	Campo (ARCA)	A	B	C	Cuándo es obligatorio
idempotency	—	●	●	●	Siempre. Es de NanoFactura, no de ARCA.
posNumber	PtoVta	●	●	●	Siempre.
voucherType	CbteTipo	●	●	●	Siempre.
concept	Concepto	●	●	●	Siempre.
voucherDate	CbteFch	●	●	●	Siempre.
customer.docType	DocTipo	●	●	●	Siempre. En A tiene que ser CUIT (80).
customer.docNumber	DocNro	●	◐	◐	Siempre presente. En B y C se admite 99/0 sólo por debajo del importe que fija ARCA.
customer.name	—	●	●	●	Siempre. Se imprime en el comprobante.
customer.taxType	CondicionIVAReceptorId	●	●	●	Siempre. En A tiene que ser Responsable Inscripto (1) o Monotributo (6).
customer.address	—	○	○	○	Nunca, pero recomendado: se imprime en el PDF.
customer.stateId	—	○	○	○	Nunca, pero recomendado: ver nota.
items[]	—	●	●	●	Siempre, mínimo una línea.
items[].taxType	Iva[].Id	●	●	○	En A y B siempre. En C no va: no se discrimina IVA.
serviceFrom	FchServDesde	◐	◐	◐	Si concept es 2 o 3.
serviceTo	FchServHasta	◐	◐	◐	Si concept es 2 o 3.
serviceExpiration	FchVtoPago	◐	◐	◐	Si concept es 2 o 3.
associatedVouchers	CbtesAsoc	◐	◐	◐	En notas de crédito y débito.
currency.id	MonId	○	○	○	Nunca. Por defecto PES.
currency.quotation	MonCotiz	◐	◐	◐	Si currency.id no es PES.
cancelsInSameForeignCurrency	CanMisMonExt	◐	◐	◐	Sólo en moneda extranjera.
tributes[]	Tributos	○	○	○	Nunca. Sólo si corresponden percepciones o impuestos que no son IVA.
receiverTaxConditionId	CondicionIVAReceptorId	○	○	○	Nunca. Si se envía, pisa a customer.taxType.
emails, legend, comments, externalReference, additionalData, settings	—	○	○	○	Nunca. Son de NanoFactura, no viajan a ARCA.

Las cuatro reglas condicionales

Son las que causan casi todos los rechazos:

1. Servicios → tres fechas. Si concept es 2 (servicios) o 3 (productos y servicios), las tres fechas de servicio son obligatorias. Faltando cualquiera, la API responde 400 antes de llamar a ARCA, indicando cuál falta.

2. Nota de crédito o débito → comprobante asociado. Y de la misma letra: una nota de crédito C anula una factura C.

3. Factura A → receptor identificado con CUIT. docType tiene que ser 80, y el receptor tiene que ser Responsable Inscripto (1) o Monotributista (6). Si le facturás a un consumidor final o a un exento, el comprobante que corresponde es B.

4. Moneda extranjera → cotización. Si currency.id no es PES, mandá currency.quotation con la cotización del día. No se consulta sola.

Identificación del receptor en B y C

En Factura B y C podés facturar a consumidor final sin identificarlo (docType: 99, docNumber: "0") sólo por debajo del importe que fija ARCA. Por encima de ese monto hay que identificar al comprador con DNI o CUIT.

ARCA actualiza ese umbral periódicamente. No lo hardcodees: si te pasás, el rechazo llega con el código 10015 y un mensaje explícito.

{
  "ok": false,
  "error": "(10015) Factura B con importe total mayor a $ … requiere identificación del comprador",
  "code": "ARCA_ERROR",
  "details": [{ "code": 10015, "msg": "…" }]
}

La forma correcta de manejarlo: pedí siempre el documento si lo tenés, y tratá el 10015 como "pedile los datos al cliente y reintentá".

Lo que la API completa sola

Estos campos de ARCA no se envían: los calcula o los lleva la API.

Campo ARCA	De dónde sale
Cuit	El CUIT de tu empresa.
CbteDesde / CbteHasta	Numeración correlativa por punto de venta y tipo. No lleves contadores.
ImpNeto	Suma de las líneas gravadas (y de todas en comprobantes C).
ImpIVA	Suma del IVA calculado por línea.
ImpOpEx	Suma de las líneas exentas o al 0% (taxType 2 y 3).
ImpTotConc	Suma de las líneas no gravadas (taxType 1 o desconocido).
ImpTrib	Suma de los tributes[].subtotal.
ImpTotal	ImpNeto + ImpIVA + ImpTrib + ImpOpEx + ImpTotConc.
Iva[]	Un { Id, BaseImp, Importe } por cada alícuota gravada presente en los ítems.
Tributos[]	Un { Id, Desc, BaseImp, Alic, Importe } por cada tributes[].
Token y firma	Autenticación con ARCA, renovada automáticamente.
CAE / CAEFchVto	Los devuelve ARCA y quedan en la respuesta.

¿Por qué no se mandan los importes?

Los totales que ARCA acepta tienen reglas de redondeo estrictas y consistentes entre sí: si ImpTotal no coincide exactamente con la suma de sus partes, el comprobante se rechaza. Calcularlos de nuestro lado en la API en base a la información que envías de cantidad, precio y alícuota elimina toda una categoría de rechazos por centavos.

Por qué conviene mandar la provincia

customer.stateId no se le envía a ARCA —el domicilio que se imprime es address, en texto libre— pero es el único dato estructurado de ubicación que queda guardado con el comprobante.

Con la provincia cargada podés después:

• Saber cómo se reparte tu facturación por jurisdicción, que es la base de cualquier liquidación de Ingresos Brutos y del Convenio Multilateral.
• Filtrar y agrupar tus reportes por provincia sin trabajo manual.
• Hacer que el PDF imprima las leyendas provinciales que correspondan (defensa al consumidor, IIBB local). Sin stateId, esas leyendas no aparecen.

address es texto libre y no se puede agregar ni agrupar de forma confiable. Y no hay forma de reconstruir la provincia hacia atrás: si no la mandaste al emitir, ese dato no existe más.

Mandá null cuando genuinamente no la sepas — es un valor válido que significa "no informada", y es mejor que inventar 0 (CABA), que te ensucia los reportes con facturación que no es de CABA. Podés reenviar tal cual el stateId de la consulta de padrón.

Glosario rápido

Si venís de una integración directa, la traducción de vocabulario:

En ARCA	En NanoFactura
FECAESolicitar	POST /:id-empresa/invoices
FECompUltimoAutorizado	No hace falta: la numeración la lleva la API
FECompConsultar	No hace falta: reintentá con la misma idempotency
FEParamGetCondicionIvaReceptor	GET /:id-empresa/arca/condicion-iva-receptor
FEDummy	GET /:id-empresa/arca/dummy
Padrón A13 / Constancia de Inscripción	GET /:id-empresa/arca/padron/:docNumber
FEParamGetPtosVenta	GET /:id-empresa/pos/arca
Autenticación, token, firma, certificado	Automático: sólo mandás la API Key

Todas las tablas de códigos de ARCA, tal como las usa la API: Tablas de códigos.