Si exportás desde Argentina, el punto no es solo vender: es lograr que el pedido salga con datos correctos, documentos sin fallas y seguimiento claro.
Yo lo resumiría así: una integración aduanera sirve para unir tienda, ERP, logística, courier, Aduana y mensajería en un solo flujo de datos. Cuando eso no pasa, aparecen errores en HS code, pesos, direcciones, valores declarados y estados de envío. Y ese tipo de falla puede frenar un paquete entre 24 y 72 horas, además de sumar costos.
En simple, este proceso tiene que resolver 5 cosas:
También hay un punto que muchos pasan por alto: si falta un dato obligatorio, el pedido no debería avanzar. Ese bloqueo previo evita buena parte de las retenciones, devoluciones y reclamos.
Los temas que cubre esta guía son:
En otras palabras: no se trata solo de conectar APIs. Se trata de evitar carga manual, bajar errores y darle visibilidad al cliente de punta a punta.
Flujo de integración aduanera para ecommerce exportador
Con los datos base ya definidos, el paso que sigue es chequear qué pide Aduana antes de emitir documentos. La lógica es simple: primero se valida qué necesita cada SKU y después qué necesita cada pedido.
Cada SKU del catálogo tiene que contar, como mínimo, con estos atributos para que los documentos de exportación salgan sin carga manual:
| Campo | Formato | Ejemplo |
|---|---|---|
| Descripción aduanera | Tipo + material + uso + presentación | "Remera de algodón para mujer, manga corta, color negro" |
| Código HS | Numérico, sin puntos ni espacios, 6–10 dígitos según destino | 61091000 |
| País de origen | Código ISO + etiqueta | AR – Argentina |
| Valor unitario declarado en USD | Con conversión trazable desde ARS | USD 18,50 / $ 17.390,00 |
| Unidad de medida | Lista controlada | "unidad", "par", "pack" |
| Peso neto por unidad | Kilogramos con decimales | 1,25 kg |
| Dimensiones por unidad | Largo x ancho x alto en cm | 30 x 20 x 10 cm |
La descripción aduanera tiene que ser precisa y estar separada del título comercial. No alcanza con poner algo genérico. Las descripciones vagas, los HS faltantes y las facturas incompletas son parte de las demoras y devoluciones más comunes.
El HS code, además, conviene cargarlo una sola vez, en formato numérico, y reutilizarlo en todos los documentos. Si cambia entre sistemas, empiezan los problemas.
Una vez que los SKUs están normalizados, el siguiente control pasa por el destinatario y la dirección. Un pedido no debería entrar en estado listo para enviar si le falta alguno de estos datos.
El registro del pedido debe incluir nombre completo del destinatario, dirección separada en campos individuales - calle y número, piso/departamento, localidad, provincia, código postal y país - , teléfono con código de país, correo electrónico y documento o número fiscal que pida el destino. Por ejemplo:
Cada línea del pedido también tiene que llevar cantidad, precio unitario, total, moneda y tipo de cambio trazable.
Los rechazos más frecuentes suelen venir por fallas bastante básicas: dirección incompleta, nombre del destinatario distinto al del documento de identidad y totales de factura que no coinciden con la suma de los ítems.
Con los campos ya definidos, la integración tiene que frenar cualquier carga incompleta. Esta normalización no aplica solo al final del proceso. Tiene que correr tanto al cargar productos como al crear pedidos.
Para productos: los campos aduaneros críticos - HS code, país de origen, peso, dimensiones y descripción aduanera - deben ser obligatorios antes de que un SKU pueda publicarse para destinos internacionales. Todos los datos se guardan en unidades normalizadas: kg y cm. Y las dimensiones tienen que seguir siempre el mismo orden: largo x ancho x alto, en centímetros.
Para pedidos y clientes: los campos de dirección tienen que ser estructurados, no una caja de texto libre donde cada cliente escribe como quiere. Si el destino es Brasil, el checkout debe pedir CPF/CNPJ de forma obligatoria. Si el destino es la Unión Europea, debe pedir EORI o número de identificación nacional. Cuando falta un campo crítico, la tienda tiene que bloquear el avance y solicitar ese dato antes de dejar seguir.
Con los campos obligatorios ya completos, el sistema puede generar la documentación aduanera sin carga manual. Lo mejor es sacar todo desde el mismo order record. Así evitás desajustes entre la factura, el packing list y la declaración.
Un envío de exportación desde Argentina genera, como piso, cuatro piezas: factura comercial, packing list, declaración aduanera electrónica - CN22 o CN23, según corresponda - y etiqueta de envío. La integración tiene que enviar datos estructurados por API; después, el operador los muestra en su propio formato.
Cada documento toma lo que necesita del mismo registro:
Si el precio está cargado en ARS con IVA, el sistema debe calcular el valor neto antes de pasarlo a la moneda de declaración.
Después de generar los documentos, validalos contra el pedido antes de liberar el envío. Ese chequeo previo te ahorra un problema bastante común: datos que cierran por separado, pero no entre sí.
Validá antes de enviar al operador: corregir errores después puede tomar entre 24 y 72 horas y sumar cargos administrativos.
Como mínimo, conviene revisar estos campos:
| Documento | Fuente principal | Campos clave a validar | Prioridad |
|---|---|---|---|
| Factura comercial | Catálogo + checkout | CUIT del exportador, código HS, descripción aduanera, valor declarado, documento fiscal o de identidad del destinatario | Alta |
| Packing list | Pedido + depósito | Peso neto y bruto en kg, dimensiones en cm, cantidad por línea, número de bulto | Alta |
| Declaración aduanera (CN22/CN23) | Catálogo + logística | País de origen, código HS, valor total declarado, descripción en el idioma requerido por el destino | Alta |
| Etiqueta de envío | Checkout + carrier | Dirección estructurada, código postal válido para el destino, teléfono con código de país | Media |
También conviene automatizar tres controles de consistencia. Son simples, pero sirven para frenar errores antes de que lleguen a aduana:
Si alguno falla, bloqueá el envío y pedí corrección antes de avanzar.
Para productos restringidos - baterías de litio, cosméticos, suplementos o electrónicos con módulos inalámbricos - cruzá catálogo y destino. Si falta documentación, bloqueá el envío y derivá el caso a compliance.
Con la documentación validada, el envío queda listo para la presentación electrónica y la sincronización de estado.
Con la documentación ya validada, el paso que sigue es pasarle los datos al operador logístico. Acá hay una meta muy clara: que cada cambio de estado vuelva a la tienda y al canal de mensajería sin trabajo manual.
Recién cuando producto, pedido y documentos están validados, el operador puede aceptar la carga sin trabas. En ese momento, el sistema envía un mensaje estructurado al operador por API o webhook, con respaldo por polling si hace falta.
Ese mensaje tiene que incluir, como mínimo:
Con esos datos, el operador genera la reserva de envío (booking) y registra el número de seguimiento.
Después, el operador transmite esa información al carrier y, cuando aplica, también a aduana. En Argentina, los datos deben enviarse a ARCA antes de que llegue el paquete. Por eso, el dato de origen no puede fallar: un error en el código HS, en el valor declarado o en la dirección puede frenar el despacho.
Cada envío tiene que guardar ID de reserva, timestamp, estado y error. Si hay reintentos, conviene usar idempotency keys y audit logs. También sirve separar las confirmaciones sincrónicas - recibido o aceptado - de las actualizaciones asincrónicas - presentación aduanera o preliberación - , porque el flujo de customs suele cerrarse después de la reserva inicial.
Con esa base, el próximo paso es normalizar los eventos de tracking antes de publicar estados en la tienda.
Cada evento que entra al modelo canónico debería actualizar la tienda y el canal de atención con el mismo texto. Si soporte ve una cosa y mensajería otra, aparecen los problemas. Por eso, antes de actualizar la tienda, hay que convertir los códigos del carrier a un modelo canónico.
Además, cada evento debería traer hora, sistema de origen y ubicación, cuando esté disponible. Eso ayuda a medir SLA y a responder mejor cuando entra un reclamo.
Mapeá los códigos de cada carrier a un estado canónico antes de actualizar la tienda.
Si usás Burbuxa, puede consumir estos eventos y disparar mensajes automáticos por WhatsApp o Instagram en cada hito importante.
| Estado canónico | Evento que lo dispara | Acción recomendada |
|---|---|---|
| Etiqueta creada | Booking confirmado por el operador | Guardar tracking number; notificar al cliente con link y fecha estimada |
| Booking confirmado / manifestado | Paquete registrado y listo para la red del carrier | Actualizar la línea de tiempo del pedido |
| En tránsito | El transportista toma el paquete | Mantener el seguimiento automático |
| Revisión aduanera | El paquete ingresa a control aduanero | Notificar al cliente; recordar declaración jurada y pago de aranceles |
| Liberado | Aduana libera el paquete | Actualizar estado y avisar que sigue en reparto |
| En reparto | Último tramo de entrega | Avisar al cliente con ventana horaria si está disponible |
| Entregado | Confirmación de entrega del carrier | Confirmar entrega y solicitar reseña |
| Retención o excepción | Retención aduanera, dirección incorrecta u otro problema | Notificación proactiva con explicación y próximos pasos |
| Devolución iniciada | Retorno al origen o devolución operativa | Informar el estado y abrir gestión interna |
Si aparece una retención o una devolución, ese mismo flujo también tiene que disparar la gestión operativa.
Cuando un envío pasa de liberado a excepción, la integración entra en modo contingencia. En ese momento, hay que detectar el evento en tiempo real, normalizarlo como CUSTOMS_HOLD o DOCS_REQUESTED, abrir el caso y avisarle al cliente qué está pasando, por qué motivo y cuál es el plazo estimado.
Puertas adentro, el caso tiene que traer toda la información para destrabar la retención: SKU, código HS, valor declarado, número de factura y CUIT. Las retenciones por sospecha de subvaluación o por pedido de documentación complementaria conviene tenerlas previstas desde antes, porque cada una pide un flujo de resolución distinto. Sumá los PDFs al caso y devolvé el estado al operador por la misma integración.
Si la retención termina en devolución, el flujo cambia: ya no se trata solo de resolver papeles, sino de activar logística inversa. El retorno al origen (RTO) es el escenario de mayor costo, porque el vendedor absorbe el flete de ida, el de vuelta y el manejo extra. Por eso, el RTO tiene que pasar por estados intermedios como RTO_IN_TRANSIT y RTO_RECEIVED_WAREHOUSE hasta llegar a la inspección final.
Mientras el paquete está volviendo, el stock no puede figurar como disponible. Tiene que quedar bloqueado o marcado como en logística inversa hasta que el depósito termine la inspección. Recién después de esa revisión, el producto puede volver a venta, pasar a outlet o darse de baja contablemente.
Cuando el depósito confirma la recepción y el resultado de la inspección, la integración tiene que disparar el flujo de reembolso según la política del vendedor y el medio de pago original: tarjeta, Mercado Pago o transferencia bancaria. Los montos deben expresarse en ARS con formato local correcto, por ejemplo, AR$ 12.345,67. Y si el pago original fue en otra moneda, también hay que registrar el impacto del tipo de cambio.
Si Burbuxa está integrada con la tienda, puede resolver de forma automática las consultas de soporte sobre el estado del retorno o del reembolso. Lo hace leyendo los datos del pedido en tiempo real y respondiendo por WhatsApp o Instagram.
Con estos eventos, cerrás el circuito aduanero, logístico y de posventa.
Esta capa funciona bien cuando hay tres cosas claras:
RTO_IN_TRANSIT y RTO_RECEIVED_WAREHOUSE ayudan a evitar doble venta y fallas en reembolsos.Primero, integrá tu plataforma de ventas con Burbuxa. Ese es el punto de partida para sincronizar en tiempo real el catálogo, los pedidos, los clientes, el inventario y las políticas fiscales.
Después, sumá tu canal principal de comunicación, como WhatsApp Business API, para poner en marcha la automatización de ventas y soporte con datos actualizados desde el primer minuto.
Tus datos quedan listos para Aduana cuando cada producto tiene NCM, alícuota de IVA y una descripción precisa. En tu ecommerce, además, conviene revisar que el SKU, la unidad de medida y el país de origen estén bien cargados.
Si usás Burbuxa, la sincronización en tiempo real de productos, pedidos e inventario ayuda a mantener la información consistente y centralizada. También sirve para validar los campos fiscales obligatorios antes de exportar.
Si un envío queda retenido en aduana, lo primero es mantener la calma y mirar el panorama completo en Burbuxa. La plataforma sincroniza en tiempo real los datos del pedido, el estado del envío y la información del cliente.
Si la consulta entra por WhatsApp, el agente de IA puede responderle al cliente en el momento. Y si hace falta ayuda de una persona, deriva el caso a tu equipo con todo el contexto necesario para gestionar documentos o validaciones adicionales.