Sandbox, planes y paso a producción

Qué cuesta, qué se cuenta como consumo, y qué falta para emitir en producción. Con las dos reglas que casi nadie publica y una que hay que decir con todas las letras.

Los números de esta guía salen del modelo comercial. El comportamiento —qué consume cuota, qué pasa al excederse, qué devuelve una clave live— se ejecutó.

El sandbox es gratis y no es un simulador

Homologación ilimitada, y ARCA entrega CAE real. Los CAE de el quickstart y de las demás guías salieron de los servidores del organismo. No hay mocks en el camino: la firma, el sobre SOAP y la respuesta son los mismos que en producción.

Y la homologación no consume cuota. No es una excepción del plan Sandbox: vale en todos. Medido — emitir en homologación y mirar las cabeceras de la misma respuesta:

HTTP 201
X-Cuota-Limite: 50
X-Cuota-Usada: 0          ← cero, justo después de emitir
X-Cuota-Restante: 50
X-Cuota-Reinicio: 2026-08-01T03:00:00.000Z

Cobrar por comprobantes de prueba castigaría exactamente la conducta que el sandbox existe para fomentar.

Lo que se cobra es el comprobante autorizado

No el request, no la creación. El CAE.

Por qué importa: tu factura depende de tus ventas, no de tus decisiones de arquitectura. Si hacés tres consultas antes de emitir, o si reintentás por un timeout, la cuenta no cambia. Es la diferencia con contar requests.

Los planes

Todos incluyen panel, API, PDF A4 y ticket con QR de la RG 4892, homologación y soporte por email. El PDF no es un módulo aparte.

Precios de lista en USD, cobrados en pesos al tipo de cambio del día.

Regla 1 · CUIT activo es el que emitió, no el que aprovisionaste

Un CUIT cuenta en el período sólo si emitió al menos un comprobante autorizado. Cargar un contribuyente y dejarlo dormido no cuesta nada.

Medido, sobre la misma organización, a medida que aparecían emisiones autorizadas en producción:

sin emisiones            cuitActivos: 0
un CUIT emitiendo        cuitActivos: 1
dos CUIT emitiendo       cuitActivos: 2

Y cuitActivos se deriva por consulta, nunca se aprovisiona: no hay un contador que alguien pueda dejar mal.

Para una plataforma con tenants que entran y salen, esto es la diferencia entre pagar por lo que se usa y pagar por slots vacíos.

Regla 2 · En Plataforma el cupo va a un pozo común

Cada CUIT activo suma 150 comprobantes a una bolsa de la organización. No es un límite por tenant: es un límite compartido que crece con la cantidad de tenants que facturan.

Medido en GET /v1/consumo, cambiando sólo la cantidad de CUIT activos:

1 CUIT activo   →  "limite": 150,  "cuitActivos": 1
2 CUIT activos  →  "limite": 300,  "cuitActivos": 2

Y la cabecera de la emisión dice lo mismo, con dos CUIT activos:

X-Cuota-Limite: 300
X-Cuota-Usada: 1005
X-Cuota-Restante: 0
X-Cuota-Excedente-Unitario: USD 0.0080

Eso es lo que hace que la misma grilla sirva a un monotributista y a una plataforma con 300 tenants: un monotributista es una plataforma con N=1.

Regla 3 · La cuota es blanda. Nunca se bloquea una emisión

Ésta es la que más conviene saber antes de integrar, y está medida.

Con 1002 comprobantes usados contra un límite de 1000:

HTTP 201
X-Cuota-Limite: 1000
X-Cuota-Usada: 1002
X-Cuota-Restante: 0                        ← nunca negativo
X-Cuota-Excedente-Unitario: USD 0.0120     ← aparece SÓLO si te excediste

status: AUTHORIZED · cae: 86300697337704 · comprobante: 0001-00000138

Se emitió igual, con CAE real. No hay un 429 de cuota, no hay un 402, no hay nada que frene la emisión.

Es una decisión, no un olvido: facturar es una obligación legal, el costo marginal es cero, y en Plataforma el bloqueado no sería tu cliente sino terceros que no firmaron nada con nosotros.

Lo que sí es duro:

Excedente ≠ mora. Pasarte de la cuota es una línea más en la factura del mes.

Las cabeceras de cuota, en cada emisión

Logueá X-Cuota-Restante y vas a ver el excedente venir con semanas de anticipación, sin consultar nada.

GET /v1/consumo

El detalle completo, con el desglose por CUIT. Respuesta real:

{
  "period": "2026-07",
  "plan": "PLATAFORMA",
  "organization": {
    "limite": 300,
    "usada": 1005,
    "restante": 0,
    "excedente": 705,
    "excedenteUnitarioUsd": 0.008,
    "cuitActivos": 2,
    "reinicio": "2026-08-01T03:00:00.000Z"
  },
  "taxpayers": [
    {
      "taxpayerId": "cms6p8guh0008urdcg83j2sun",
      "cuit": "20437136697",
      "billable": 1002,
      "total": 1005
    },
    {
      "taxpayerId": "tp-6-6-b",
      "cuit": "30500001735",
      "billable": 3,
      "total": 3
    }
  ]
}

Mirá la diferencia entre billable y total en el primer CUIT: 1002 facturables sobre 1005 operaciones. Los tres de diferencia son emisiones de homologación — contadas, no cobradas.

El desglose por contribuyente existe porque una plataforma necesita saber el consumo de cada tenant, para su propio recobro o para poner sus propios límites.

El consumo no se puede corregir "a mano", y está enforzado

Cada operación deja un evento crudo inmutable, y las cuotas se calculan encima. No hay un contador que alguien pueda incrementar o retocar.

No es una convención: la base lo rechaza. Intentando corregir eventos directamente en Postgres:

UPDATE "UsageEvent" SET result='RECHAZADO' WHERE ...
ERROR: UsageEvent es inmutable (MODELO-COMERCIAL.md §5, regla 1): UPDATE rechazado.
       Las cuotas se calculan sobre los eventos, no se corrigen encima.

DELETE FROM "UsageEvent" WHERE ...
ERROR: UsageEvent es inmutable (...): DELETE rechazado.

Para vos eso significa dos cosas: tu factura es auditable hacia atrás, y si alguna vez cambia la unidad de cobro, se puede recalcular el histórico y mostrarte los dos números antes de anunciar nada.

El paso a producción, como es

Emitir en PRODUCCION está habilitado. Hasta la 5.10 esta guía decía lo contrario, y era cierto: había un 422 ARCA_PRODUCTION_NOT_SUPPORTED puesto a propósito. Se levantó, y con él se fue el código de error.

Lo que emitís en PRODUCCION es un comprobante fiscal real. Entra en tus registros ante ARCA, pesa en tu declaración y no se borra: se revierte con una nota de crédito. Para probar está HOMOLOGACION, que también emite con CAE real y no tiene consecuencia fiscal.

Los controles que sí quedan, y que son los que vas a ver:

Un integrador que prueba con su clave de sandbox nunca llega a emitir en producción por accidente: ve un 403 que habla de modos y no de ambientes.

Y algo que Emissa no verifica, a propósito: que tengas el certificado productivo, el punto de venta de tipo "Factura Electrónica – Web Service" y el servicio autorizado en ARCA. Esas tres cosas viven del lado del organismo, y si falta alguna te lo dice ARCA con el motivo concreto. Una guarda nuestra sólo podría adivinar.

La consecuencia que nadie adivinaría

La cuota sólo cuenta comprobantes de PRODUCCION. Mientras producción estuvo deshabilitada eso quería decir que no había forma de consumir cuota emitiendo, y la única manera de llegar a un excedente era sembrar eventos a mano — que es exactamente cómo se midió la regla 3.

Desde la 5.10 eso cambió: emitir en producción consume cuota de verdad. El sandbox sigue siendo gratis e ilimitado en lo que a cuota respecta, así que la frontera entre "probar" y "pagar" es la misma que la frontera entre "no tiene consecuencia fiscal" y "sí la tiene". No es una coincidencia: es el mismo límite mirado desde dos lados.

Qué hace falta para producción

Tres cosas, y dos son trámites tuyos ante ARCA:

1. Un certificado productivo, distinto del de homologación.
2. El punto de venta dado de alta para "Factura Electrónica – Webservice" en el ambiente productivo. Ver qué es un punto de venta.
3. Que la emisión en PRODUCCION esté habilitada del lado de Emissa.

Mientras tanto, todo lo que construyas contra el sandbox sirve sin cambios: es la misma API, los mismos códigos de error y el mismo circuito. Lo único que cambia es el ambiente del contribuyente y el modo de la clave.

Qué sigue

• Cómo se arma una integración — el recorrido completo.
• Todos los errores — la tabla de consulta.