Facturación electrónica de ARCA: ¿web service directo o un SDK pago?

Si buscás cómo emitir factura electrónica desde tu sistema, casi todos los resultados vienen del mismo lugar: empresas que venden un SDK o una API paga. No están mintiendo, pero tampoco van a explicarte cuándo no las necesitás.

Esta nota no vende ninguno de los dos caminos.

Qué hay que hacer, sin intermediarios

Emitir un comprobante contra ARCA son dos servicios encadenados.

Primero WSAA, el de autenticación. Se le manda un pedido firmado con un certificado X.509 propio y devuelve un ticket de acceso: un token y una firma que después viajan en cada llamada. El certificado se tramita, se asocia al servicio que se va a usar, y el de pruebas no sirve en producción — son dos ambientes con dos certificados.

Después WSFEv1, el de facturación, que recibe el comprobante y devuelve el CAE: el código de autorización sin el cual la factura no es válida.

Los dos son SOAP. En un stack moderno eso significa armar sobres XML, firmar con CMS y parsear respuestas con namespaces, que es un tipo de trabajo que la mayoría de los lenguajes dejó de hacer cómodo hace quince años.

Qué te compra un SDK

Te saca la plomería: el SOAP, la firma, el manejo del ticket y los reintentos. Le pasás un JSON y te devuelve el CAE. Para un equipo que factura ocasionalmente y no quiere tener a nadie mirando eso, es una compra razonable.

Lo que te ata: una dependencia externa en el camino de una operación que es legalmente obligatoria. Si el proveedor se cae, tu facturación se cae — y no fue ARCA la que se cayó. Y el costo suele escalar por comprobante o por mes, así que crece justo cuando el negocio crece.

El criterio

No es cuál es más "profesional". Es dónde querés tener el mantenimiento.

• Facturás poco y no es el centro de tu producto → SDK. El tiempo que ahorrás vale más que la cuota.
• La facturación ES tu producto, o el volumen hace que la cuota pese → directo. La complejidad se paga una vez; la cuota, todos los meses.
• Tenés que emitir tipos de comprobante poco comunes → directo. Los SDK cubren bien lo frecuente y se ponen incómodos en los bordes.
• No hay nadie que pueda mantener una integración SOAP → SDK, sin culpa. Una integración que nadie puede tocar es peor que una cuota.

Hay un tercer camino que se elige poco: hacerlo directo y encapsularlo detrás de una interfaz propia. Cuesta como el directo, pero deja cambiar de estrategia después sin tocar el resto del sistema.

Los errores que te vas a comer igual

Elijas el camino que elijas, hay problemas que son del servicio y no de la integración. Conviene saberlos antes de prometer una fecha.

• El servicio se cae o se pone lento, y suele hacerlo en los días de vencimiento — justo cuando más se factura. Tu sistema tiene que poder encolar y reintentar, no perder la venta.
• La numeración es correlativa por punto de venta y tipo de comprobante. Si tu sistema asigna el número antes de tener el CAE y esa emisión falla, dejaste un hueco. Consultá el último autorizado al servicio en vez de llevar la cuenta por tu lado.
• Los datos del receptor tienen que ser consistentes con lo que ARCA ya sabe de ese CUIT. Un tipo de comprobante que no corresponde a la condición del receptor se rechaza.
• El certificado vence. Nadie se acuerda hasta que la facturación se detiene un lunes.

Antes de salir a producción

• Probá en homologación con el certificado de ese ambiente: el de producción no funciona ahí, y al revés tampoco.
• Guardá y reusá el ticket de acceso. Es el error más común.
• Guardá el CAE y su vencimiento con el comprobante. Es el dato que prueba que la factura es válida.
• Numeración correlativa por punto de venta y tipo de comprobante: un salto lo rechaza el servicio.
• Encolá las emisiones: el servicio se cae, y perder la venta por eso no es aceptable.
• Agendá el vencimiento del certificado.