Homologación vs producción en ARCA: diferencias

ARCA (ex AFIP) mantiene dos ambientes completamente separados: homologación, para probar, y producción, donde los comprobantes tienen validez fiscal. Entender en qué difieren, y dónde se decide a cuál apunta tu cuenta, evita emitir de más en producción o probar contra un ambiente que no corresponde.

Los dos ambientes en una tabla

	Homologación	Producción
Para qué sirve	Probar la integración	Emitir comprobantes con validez fiscal
CAE	De prueba, sin validez fiscal	Válido ante ARCA
WSAA	`wsaahomo.afip.gov.ar`	`wsaa.afip.gov.ar`
WSFEv1	`wswhomo.afip.gov.ar`	`servicios1.afip.gov.ar`
Certificado	El de homologación, emitido por separado	El de producción
Punto de venta	No exige alta previa en ARCA	Debe estar dado de alta y habilitado
Receptor con CUIT	Se valida contra el padrón propio de homologación	Se valida contra el padrón real

Dónde se decide el ambiente de tu cuenta

En YoFacturo el ambiente es una configuración de la cuenta, no un parámetro de cada request. Vive en el contribuyente activo, en el campo afip_environment, que vale testing (homologación) o production. Si el campo falta, se toma production. Ningún cuerpo de un request puede forzar el ambiente: todos los comprobantes se autorizan contra el que tiene configurado la cuenta. Es una decisión deliberada, para que un error en un script no emita un comprobante real por accidente.

Para leerlo: GET /bill/tax_info/taxpayer/ (scope accounting:read) devuelve afip_environment.
Para cambiarlo: POST /bill/tax_info/afip-environment/ (scope accounting:write) con el cuerpo {"environment": "testing"} o {"environment": "production"}.

Las cuentas de prueba que la plataforma marca como bloqueadas no pueden pasar a producción con ese endpoint: el pedido se rechaza y hay que solicitarlo al equipo de YoFacturo. Las rutas son relativas a https://api.yo-facturo.com/api/v1.

Qué CUIT y qué certificado se usan en homologación

En homologación no necesitás tener tu propio certificado ni haber delegado nada. Una cuenta en testing siempre emite con el CUIT de homologación de la plataforma y su certificado de homologación, aunque tengas tu CUIT real cargado en el perfil fiscal. Seguís viendo tu CUIT en la interfaz y en los payloads; el intercambio con ARCA es interno. Esto se aplica solo en testing: en producción emitís como tu CUIT, con la delegación aceptada (ver delegación).

Puntos de venta y numeración: la trampa de compartir CUIT

Como todas las cuentas de homologación comparten el CUIT de la plataforma, también comparten la numeración: ARCA lleva la secuencia por combinación de CUIT, punto de venta y tipo de comprobante. Dos equipos probando el mismo punto de venta y el mismo tipo se pisan los números. La salida es simple y está permitida: elegí un punto de venta que no usen otros. En homologación no hace falta registrarlo en ARCA. En una prueba real, una Factura B emitida sobre un punto de venta inexistente obtuvo CAE igual.

En producción es al revés: el punto de venta tiene que estar dado de alta como de tipo web service. Si no lo está, ARCA responde 11002 o 501, y YoFacturo consulta los puntos de venta habilitados para decirte cuáles sí funcionan. El alta se explica en la guía de punto de venta.

Hay una excepción: el punto de venta de CAEA debe estar registrado como tal en ARCA aun en homologación. Si no, los informes fallan con 1204. Se cuenta en la guía de CAEA por API.

La numeración local de YoFacturo también distingue ambientes: el contador es por cliente, CUIT, punto de venta, tipo y ambiente. Emitir en testing no mueve el contador de producción.

Un error típico de homologación: el receptor

Si emitís una factura A con el CUIT de un receptor y ARCA responde 10069, el motivo es que homologación valida el CUIT del receptor contra su propio padrón. Un CUIT con el dígito verificador correcto no alcanza. Para probar, usá un documento que exista en ese padrón o un DNI (tipo_documento 96).

Checklist antes de pasar a producción

La delegación del web service de facturación da delegation_verified: true (POST /bill/tax_info/verify-delegation/).
El punto de venta de tipo web service existe y POST /bill/tax_info/verify-punto-venta/ lo marca como válido.
GET /bill/receipts/supported-types/ lista los tipos de comprobante que vas a emitir para tu condición fiscal.
Cambiás la cuenta con POST /bill/tax_info/afip-environment/.
Antes de emitir, consultás el último número autorizado con GET /afip_ws/ws/voucher-last/{sale_point}/{voucher_type}/. La respuesta incluye el campo environment, para que no compares contra un ambiente que no es el tuyo.

Mientras integrás y probás, mantené la cuenta en testing. Para ver qué cubre la API, mirá la página de facturación electrónica por API.