Overselling es vender o aceptar más unidades de un producto que las que realmente están disponibles. En operaciones multicanal, una causa frecuente son los retrasos o desajustes de sincronización de stock entre sistemas.
El síntoma: vender algo que ya no tenés
Si tu ecommerce ya está en producción y vendés en más de un canal (tienda propia, marketplace, punto de venta físico), es probable que en algún momento un cliente haya comprado un producto que en realidad no estaba disponible. Eso es overselling. En operaciones multicanal, el riesgo aumenta cuando los distintos sistemas no comparten una visión suficientemente actualizada y consistente del inventario.
Según describe Cin7, esos retrasos o desajustes de sincronización aparecen especialmente cuando la misma operación se vende en más de un canal. En integraciones que sincronizan por lotes (batch) en vez de en tiempo real, esa ventana puede rondar los 15 a 30 minutos, según Bizowie — no es una duración universal, depende de cómo esté configurada cada integración. Un producto se vende en un canal a las 10:05, pero si el otro sistema sincroniza cada 25 minutos, no se entera hasta las 10:30. Durante esa ventana, el producto aparece disponible en todos lados aunque ya no lo esté.
Sincronizar más seguido reduce la ventana de desactualización, pero no resuelve por sí solo el problema de concurrencia y disponibilidad.
Por qué ocurre: stock como número global vs. stock como registro transaccional
La mayoría de los sistemas básicos tratan el inventario como una cantidad global: “tengo 40 unidades del producto X”. Pero en la operación real, esas 40 unidades nunca son un solo número homogéneo. Según el análisis de Bizowie, el inventario existe simultáneamente en múltiples estados — asignado a órdenes pendientes, en tránsito, en cuarentena, disponible real — y un sistema que lo colapsa todo en un único contador pierde esa distinción.
A esto se suma algo estructural: en integraciones entre sistemas externos no debe asumirse latencia cero ni consistencia instantánea — influyen los rate limits de las APIs, el procesamiento asíncrono, la entrega de eventos, fallas puntuales y el tiempo de propagación. Por más optimizada que esté la integración, siempre hay una ventana, por pequeña que sea.
La combinación de un modelo de disponibilidad demasiado simple y una sincronización no instantánea aumenta el riesgo de overselling en operaciones multicanal, especialmente cuando varios canales compiten por el mismo inventario.
Un patrón más robusto: inventario por ubicación y producto con movimientos históricos
En vez de mantener un contador global mutable, un patrón más robusto es llevar el inventario como una serie de movimientos transaccionales por ubicación y por producto: cada entrada, salida y reserva queda registrada como un evento, y la disponibilidad se calcula a partir de esa historia en vez de sobreescribir un número.
Esto es exactamente lo que implementamos en Pymerce, la plataforma de gestión y ventas de Flexora: el stock no es un campo que se actualiza in place, es un historial de movimientos por ubicación y producto. Esa decisión de diseño aporta trazabilidad completa y una fuente central para calcular disponibilidad de forma consistente: aunque haya múltiples canales de venta pegando contra el mismo inventario, cada movimiento queda registrado y es posible detectar y reconciliar inconsistencias. Un ledger de movimientos resuelve eso — trazabilidad y fuente de verdad —, pero prevenir carreras entre ventas simultáneas (que dos canales reserven la misma unidad en el mismo instante) requiere además mecanismos de reserva o asignación de inventario y control de concurrencia en el sistema que procesa las ventas.
Este enfoque se alinea con lo que documenta ECOSIRE sobre arquitecturas de sincronización en tiempo real (fuente secundaria de arquitectura de mercado, no normativa, pero consistente con patrones ampliamente documentados en la industria): usar una base de datos transaccional como fuente de verdad, webhooks como disparador principal de actualizaciones, y polling con reconciliación periódica como respaldo para los casos donde el webhook falla o la plataforma no lo soporta.
Cuando el pedido, el pago y el inventario se ejecutan en servicios o sistemas independientes, un patrón habitual para coordinarlos es el patrón Saga: cada paso local se ejecuta y confirma por separado, y si uno falla (por ejemplo, el pago), los pasos anteriores se revierten mediante una acción compensatoria en vez de depender de una única transacción distribuida (documentado por Temporal). Aplicado al stock, esto significa reservar la unidad como parte del saga del pedido y liberarla si el pago no se completa, en vez de dejarla bloqueada indefinidamente — una reserva pendiente de pago no es lo mismo que “consistencia eventual” en el sentido estricto del término, es una compensación explícita dentro de un flujo de negocio.
El rol de la facturación electrónica en el flujo del pedido
Un segundo punto de diseño es evitar acoplar innecesariamente la confirmación de la venta con la comunicación fiscal dentro de una única operación síncrona.
Documentación de Adobe Commerce señala que una orden queda editable y cancelable hasta que se recibe el pago y se genera el comprobante — el momento exacto en que se dispara la facturación depende de cómo esté configurado el método de pago, no es un instante fijo universal.
En Paraguay, la facturación electrónica bajo SIFEN separa tres momentos distintos, según el Decreto N° 872/2023 y las preguntas frecuentes de e-Kuatia de la DNIT: primero, el facturador genera y firma digitalmente el Documento Electrónico (DE) y lo envía al comprador; segundo, transmite ese XML firmado a la DNIT para su proceso de aprobación; tercero, la DNIT valida el documento y, si lo aprueba, lo convierte en Documento Tributario Electrónico (DTE) con validez jurídica, fuerza probatoria e incidencia tributaria. El modelo e-Kuatia transaccional (el orientado a medianos y grandes facturadores) opera de forma diferida: la norma establece, con carácter general, que la transmisión debe completarse hasta 72 horas después de la fecha y hora de la firma electrónica cualificada, aunque la DNIT puede fijar plazos menores o exigir aprobación previa según el perfil del facturador.
Información sobre SIFEN revisada al 25/09/2026.
Esto significa que, cuando el régimen aplicable al facturador lo permite, la integración puede desacoplar la respuesta de SIFEN del flujo comercial: la venta se confirma y el DE queda generado y firmado de inmediato, mientras la transmisión a la DNIT se encola y reintenta dentro del plazo correspondiente si el servicio tarda o tiene una caída puntual. En Pymerce resolvimos esto separando el registro de la venta de la comunicación con el ente fiscal, para no confundir la emisión del comprobante (que ocurre en la oportunidad fiscal aplicable a la operación) con su transmisión y aprobación (que sigue el cronograma que fije la norma para cada perfil de facturador).
Este artículo no cubre costos ni plazos de implementación de facturación electrónica en Paraguay — para eso, ver cuánto cuesta integrar SIFEN con la DNIT.
No existe un único evento técnico del ecommerce — fulfillment, captura de pago, confirmación de envío — que determine de forma universal cuándo debe dispararse la emisión del comprobante: esa oportunidad fiscal depende de la operación y del perfil del facturador. Lo que sí tiene reglas explícitas es la transmisión del DE a la DNIT una vez generado, con el plazo de 72 horas como referencia general del modelo transaccional.
| Problema | Patrón útil | Límite |
|---|---|---|
| Contador global de stock | Ledger de movimientos | No resuelve por sí solo la concurrencia |
| Ventas simultáneas | Reservas / asignación | Requiere política de expiración o compensación |
| Eventos de sincronización perdidos | Webhooks + polling | La consistencia no es instantánea |
| Disponibilidad de SIFEN | Transmisión desacoplada | Hay que respetar la oportunidad de emisión y los plazos de la DNIT |
Qué revisar en tu operación ahora
Si ves overselling recurrente, revisá esto antes de pensar en sincronizar más rápido:
- ¿Tu stock se modela como un número global que se sobreescribe, o como un historial de movimientos por ubicación y producto?
- ¿La confirmación de la venta depende de que la comunicación con el ente fiscal termine exitosamente, o son dos pasos desacoplados?
Estas son dos decisiones de arquitectura que conviene revisar primero cuando aparecen overselling o ventas bloqueadas en integraciones ecommerce-ERP.
En Flexora trabajamos estas integraciones desde servicios de e-commerce y automatizaciones e integraciones. El módulo de ecommerce de Pymerce, que aplica estos mismos patrones de inventario transaccional y facturación desacoplada, está actualmente en desarrollo, en su fase final.
Si todavía estás en la etapa de planificar tu ecommerce desde cero, el checklist inicial está en qué necesita un ecommerce en Paraguay.
Fuentes citadas
- Cin7 — Overselling in ecommerce
- Bizowie — Why real-time inventory breaks down in high-volume ecommerce
- ECOSIRE — Real-time inventory sync with webhooks and queues
- Temporal — Mastering Saga patterns for distributed transactions
- Adobe Commerce — Order processing
- Decreto N° 872/2023 — incorpora nuevos comprobantes al SIFEN (DNIT, oficial)
- DNIT — Preguntas frecuentes e-Kuatia